Web漏洞(四)业务相关漏洞

业务相关漏洞

业务逻辑篡改

密码修改/重置流程跳过

漏洞描述

高危漏洞,密码修改功能常采用分步骤方式来实现,攻击者在未知原始密码的情况下绕过某些检验步骤修改用户密码。有些密码修改/重置流程采用step=1、step=2类似的方式实现,如果应用校验不全面,攻击者可绕过前面的步骤,直接访问最后一步,输入新密码进行修改/重置。

漏洞挖掘

(1)完成修改/重置密码的正常流程;

(2)绕过检验原密码等步骤,直接访问输入新密码页面,输入新密码,修改/重置密码。

漏洞修复

一次性填写校验信息(原始密码、新密码等)后再提交修改/重置密码请求。

负值反冲

漏洞描述

高危漏洞,应用程序未校验订单数据的取值范围,交易存在负值反冲。通过篡改订单参数,使得订单金额为负值,在使用余额支付时余额反而增加。

漏洞挖掘

提交订单时拦截请求,修改订单参数为负数,如商品单价、数量、总价等。

漏洞修复

1.服务器端在生成交易订单时,商品的价格从数据库中取出,禁止使用客户端发送的商品价格。
2.服务器端对客户端提交的交易数据(如商品ID、商品数量、商品价格等)的取值范围进行校验,将商品ID和商品价格与数据库中的数据对比校验,商品数量为大于零的整型数。
3.服务器端在生成支付订单时,对支付订单中影响支付金额的所有因素(比如商品ID、商品数量、商品价格、订单编号等)进行签名,对客户端提交的支付订单进行校验。

正负值对冲

漏洞描述

应用程序未校验订单数据的取值范围,交易存在正负值对冲。由于应用会校验订单总金额的取值范围,所以在保证该条件满足的前提下,修改个别商品的数量,达到正负值对冲。

漏洞挖掘

提交订单(包含多种商品)时拦截请求,修改部分商品的单价或数量,保证订单总金额为正数。

漏洞修复

1.服务器端在生成交易订单时,商品的价格从数据库中取出,禁止使用客户端发送的商品价格。
2.服务器端对客户端提交的交易数据(如商品ID、商品数量、商品价格等)的取值范围进行校验,将商品ID和商品价格与数据库中的数据对比校验,商品数量为大于零的整型数。
3.服务器端在生成支付订单时,对支付订单中影响支付金额的所有因素(比如商品ID、商品数量、商品价格、订单编号等)进行签名,对客户端提交的支付订单进行校验。

业务流程跳跃

漏洞描述

业务逻辑流程分步骤进行且能越过中间校验步骤直接进行后续操作,导致中间校验等步骤失效。

漏洞挖掘

(1)首先完成正常的业务逻辑步骤,获取每一个步骤的请求;

(2)绕过中间步骤,直接访问最后一个或几个验证请求,看是否可绕过。

漏洞修复

1.建议在不影响业务的前提下,在Session中添加对每一步流程页面的校验标志位,在新步骤页面浏览过程中,仅能够顺序执行页面校验,不可进行跳步操作,例如:页面二完成后,应更新Flag=3,则仅能够打开页面三。

业务功能失效

通配符注入

漏洞描述

中危漏洞,允许使用通配符构造语句查询数据库,导致拒绝服务攻击问题。

漏洞挖掘

模糊查询时输入第一个字符'%'或'_',sql会遍历全表,导致应用访问缓慢。

漏洞修复

1.将通配符转义为普通字符

业务功能滥用

短信可定向转发

漏洞描述

高危漏洞,短信接收人可任意指定,攻击者可利用该漏洞将验证码发送到自己的手机号上,重置他人密码或转账。

漏洞挖掘

系统向账号绑定的手机号发送短信时,拦截发送短信的请求,将手机号改为测试人员的手机号,测试是否可接收短信验证码。

漏洞修复

1.发送短信时手机号从当前会话中获取,避免从前端传入
2.用户的手机号不能随意变动,需要认证过程。

邮件可定向转发

漏洞描述

高危漏洞,应用系统发送邮件的接收人可由客户端任意指定,攻击者可利用该漏洞将邮件发送到自己的邮箱中,重置他人密码。

漏洞挖掘

拦截发送邮件的请求,将接收人邮箱改为测试人员的邮箱地址,测试是否可接收邮件。

漏洞修复

1.发送邮件时邮箱从当前会话中获取,避免从前端传入
2.用户的邮箱不能随意变动,需要认证过程。

业务接口调用缺陷

漏洞描述

应用的业务接口存在缺陷,可以通过业务接口直接进行恶意操作。攻击者可通过编写API枚举脚本,恶意调用敏感接口,从而进行提交数据等操作。

【高危】:通过业务接口能够操作核心业务内容,进行越权
【高危】:通过业务接口能够获得重要敏感数据
【中危】:通过业务接口能够获得中等程度敏感数据

漏洞挖掘

把业务逻辑和功能模块呈现的内容结合,推测出隐藏的API接口。可以到github上用域名搜索,如用户信息的接口是http://www.xxx.com/api/user/userInfo;推测重置密码接口可能是http://www.xxx.com/api/user/passReset;文件上传接口是http://www.xxx.com/api/user/uploadFile等,如果这些接口没有限制访问,则可以直接调用并提交数据。

漏洞修复

对于每一个访问的接口都首先检查当前用户是否已经登录并授权(不需要认证的接口除外,例如,免费下载接口等)

IMAP/SMTP注入

漏洞描述

电子邮件注入允许恶意攻击者注入任何邮件头字段,BCC、CC、主题等,它允许黑客通过注入手段从受害者的邮件服务器发送垃圾邮件。要向邮件服务器注入命令,前提条件是允许用户通过webmail应用程序访问其端口25(SMTP)和143(IMAP)。

【高危】:可成功劫持密码找回等信息
【高危】:可成功发送垃圾邮件

漏洞挖掘

要利用SMTP注射,用户必须事先通过认证,所以用户必须有一个有效的邮箱帐户。通过SMTP发送电子邮件消息的格式如下:

* 发送方的e-mail地址 
* 接收方的e-mail地址 
* 主题 
* 消息主体 
* 附件

CC/BCC注入

抓包,在发送者字段后注入CC和BCC参数

From:sender@domain.com%0Acc:recipient@domain.com%0Abcc:recipient1@domain.com 

现在,消息将被发送到recipient和recipient1账户。

常见的标题头字段说明:

  • cc:抄送。
  • bcc:密送。
  • %0A:回车 也可以用\n换行代替
  • return-path:邮件的回复地址。
  • from:发件人地址。
  • to:收件人地址。
  • subject:邮件主题,即邮件名。
  • body:邮件内容。
  • date:邮件发送日期。

参数注射

From:sender@domain.com%0ATo:attacker@domain.com 

现在消息将被发送到原来的收件人和攻击者帐户。注意,这里的攻击者的账户是我们通过注入额外传入的。

邮件主题注入

From:sender@domain.com%0ASubject:This’s%20Fake%20Subject

攻击者注入的假的主题subject将被添加到原来的主题中并且在某些情况下将取代原本的主题subject。这取决于邮件服务行为。即代码编写的容错性,当参数中出现两个subject的时候代码是选择丢弃还是后者覆盖。

改变消息的主体body

//要注意SMTP的Mail格式,消息主题和头部Header之间有两个换行符(和HTTP是一样的)。
From:sender@domain.com%0A%0AMy%20New%20%0Fake%20Message

假消息将被添加到原始消息中。

漏洞修复

1.所有用户输入应该被认为是不可信的。使用正则表达式来过滤用用户提交的数据。例如,可以在输入字符串中搜索(r 或 n)。
2.使用外部组件和库,例如ZEND mail、PEAR mail和swift mailer。
3.ModSecurity(waf)可以阻止服务器级别的电子邮件注入。利用ModSecurity,可以检测通过POST或GET提交的CC, BCC或目的地址,并且拒绝任何包含这些字母请求。

引用第三方不可用脚本/URL

漏洞描述

页面中引用了不可控的脚本或超链接,攻击者可在网站中插入恶意链接或脚本,导致正常用户浏览时cookie被窃取或被种植病毒木马。

【高危】:存在不可控外链或脚本,且未经过审批
【中危】:存在不可控外链或脚本,但可提供审批记录

漏洞挖掘

检查页面内容,是否引用了第三方未知脚本或超链接,如恶意的js脚本或病毒木马的下载链接等。

漏洞修复

建议在不影响业务的前提下,对网站引用的文件和源代码进行审查,一经发现有未审批的外链或脚本,应立即删除。

未验证的URL跳转

漏洞描述

高危漏洞,服务端未对传入的跳转url变量进行检查和控制,可能导致可恶意构造任意一个恶意地址,诱导用户跳转到恶意网站,通过篡改URL跳转参数可跳转至任意网址。

漏洞挖掘

(1)首先找到网站相关url中存在跳转链接的参数(如登陆页面)。

(2)在检测的同时,可以修改参数中的合法URL为非法URL,然后查看是否能正常跳转或者通过抓包工具获取其HTTP响应头中Host:的值是否包含了构造的URL。

(3)如果是struts2重定向漏洞,则可通过web扫描工具扫描发现,或者手工验证,直接在URL后添加?redirect:+指定钓鱼链接。

漏洞修复

对传入的URL做有效性的认证,保证该URL来自于信任域。限制的方式可参考以下两种:
1.限制Referer,通过限制Referer保证将要跳转URL的有效性,避免攻击者生成自己的恶意跳转链接;
2.加入有效性验证Token,保证所有生成的链接都来自于可信域,通过在生成的链接里加入用户不可控的Token对生成的链接进行校验。

服务器请求伪造SSRF

漏洞描述

服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。

【高危】:有回显,可探测内网,文件访问
【中危】:无回显,但可访问外网

漏洞挖掘

在网站一下功能处重点测试

(1)分享:通过URL地址分享网页内容

(2)转码服务:通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览

(3)在线翻译:通过URL地址翻译对应文本的内容。提供此功能的国内公司有百度、有道等

(4)图片加载与下载:通过URL地址加载或下载图片

(5)图片、文章收藏功能

(6)从URL关键字中寻找

可以看看SSRF 这篇文章

漏洞修复

1.过滤内网服务器对公网服务器请求的响应。如果Web应用是获取某一类型的文件,在把返回结果展示给用户之前应先验证返回的信息是否符合文件类型标准,比如返回信息应为图片,如果返回信息是HTML,则停止将返回信息返回客户端。
2.统一错误提示信息,避免用户可以根据错误信息来判断远端服务器的端口状态。
3.在内网服务器的防火墙上限制公网服务器的请求端口为HTTP等协议常用端口,如:80、443、8080、8090。
4.若公网服务器的内网IP与内网无业务通信,建议将公网服务器对应的内网IP列入黑名单,避免应用被用来获取内网数据。
5.内网服务器禁用不必要的协议,仅允许HTTP和HTTPS请求,防止类似于file:///、gopher://、ftp:// 等协议引起的安全问题。

短信内容可控

漏洞描述

短信内容可从客户端指定,攻击者可利用该漏洞,借助短信平台,编辑钓鱼短信发送给其他用户。

【高危】:短信内容可控,且接收人可任意指定
【中危】:短信内容可控,但接受人不可控

漏洞挖掘

在客户端编辑任意短信内容,测试是否过滤特殊内容。

漏洞修复

建议在不影响业务的前提下,禁止客户端编辑短信内容。

邮件内容可控

漏洞描述

应用系统发送邮件的邮件内容可由客户端任意指定,攻击者可利用该漏洞,借助邮件平台,编辑钓鱼邮件发送给其他用户。

【高危】:邮件内容可控,且收件人可任意指定
【中危】:邮件内容可控,但收件人地址不可控

漏洞挖掘

在客户端编辑任意邮件内容,测试是否过滤特殊内容。

漏洞修复

建议在不影响业务的前提下,禁止客户端编辑邮件内容。

请求重放攻击

漏洞描述

关键业务操作未作token或者唯一标识码,导致攻击者可以重复多次进行请求,导致恶意操作。如重复交易等问题。攻击者恶意或欺诈性地重复发送一个有效的数据包,如果服务器未检查此类重复提交的请求数据的有效性,那么转账充值等敏感操作将有可能会被重复执行。

【高危】:关键业务操作请求未设置 token 或标识码,导致业务数据越界或错误

漏洞挖掘

重放http请求,查看第二次请求是否被正常处理。

漏洞修复

服务端应用程序应检查客户端提交的数据的唯一性,如使用流水号、时间戳、token等,并将流水号、时间戳等进行签名。

批量提交

漏洞描述

应用程序未使用验证码等防自动化操作的方法,可批量提交请求,如批量注册。注册不需要验证码时,攻击者通过编写自动化脚本,实现程序自动提交注册信息;若注册需要验证码,但验证码位数不多于4位且为纯数字时,通过使用软件burpsuite的intruder功能穷举得到正确的验证码后,再结合自动化脚本工具即可实现批量注册垃圾账号。

【高危】:正常业务为单条数据请求,且不存在防自动化批量操作措施,可批量自动化提交。
【低危】:正常业务为单条数据请求,且存在防自动化批量操作措施,但在单个数据包中写入批量数据,可成功提交,并且服务器能批量

漏洞挖掘

(1)编写自动提交HTTP数据包的脚本;

(2)或使用burpsuite的intruder功能批量提交请求。

漏洞修复

1.使用安全性强的验证码,验证码应从以下方面保证其安全性:验证码长度不低于4位,避免使用容易被程序自动识别的验证码,验证码不应返回客户端。
2.用户注册功能处,提交注册信息后进行邮箱或短信验证通过后再将注册信息写入数据库。
3.对同一IP地址短时间内提交请求的次数进行限制。

Web漏洞(五)防护功能相关漏洞

posted @ 2022-04-15 13:42  九天揽月丶  阅读(423)  评论(0编辑  收藏  举报