逻辑漏洞挖掘一直是安全测试中“经久不衰”的话题。相比SQL注入、XSS漏洞等传统安全漏洞,现在的攻击者更倾向于利用业务逻辑层的应用安全问题,这类问题往往危害巨大,可能造成了企业的资产损失和名誉受损,并且传统的安全防御设备和措施收效甚微。今天漏洞盒子安全研究团队就与大家分享Web安全测试中逻辑漏洞的挖掘经验。
一:订单金额任意修改
解析
很多中小型的购物网站都存在这个漏洞。在提交订单的时候抓取数据包或者直接修改前端代码,然后对订单的金额任意修改。
如下图所示:
经常见到的参数大多为
rmb
value
amount
cash
fee
money
等
关于支付的逻辑漏洞这一块还有很多种思路,比如相同价格增加订单数量,相同订单数量减少产品价格,订单价格设定为负数等等。
预防思路
1. 订单需要多重效验,如下图所演示。
2. 订单数值较大时需要人工审核订单信息,如下图所演示。
3. 我只是提到两个非常简单的预防思路,第二个甚至还有一些不足之处。这里需要根据业务环境的不同总结出自己的预防方式,最好咨询专门的网络安全公司。
二:验证码回传
解析
这个漏洞主要是发生在前端验证处,并且经常发生的位置在于
账号密码找回
账号注册
支付订单等
验证码主要发送途径
邮箱邮件
其运行机制如下图所示:
黑客只需要抓取Response数据包便知道验证码是多少。
预防思路
1. response数据内不包含验证码,验证方式主要采取后端验证,但是缺点是服务器的运算压力也会随之增加。
2.如果要进行前端验证的话也可以,但是需要进行加密。当然,这个流程图还有一些安全缺陷,需要根据公司业务的不同而进行更改。
三.未进行登陆凭证验证
解析
有些业务的接口,因为缺少了对用户的登陆凭证的效验或者是验证存在缺陷,导致黑客可以未经授权访问这些敏感信息甚至是越权操作。
常见案例:
1. 某电商后台主页面,直接在管理员web路径后面输入main.php之类的即可进入。
2. 某航空公司订单ID枚举
3. 某电子认证中心敏感文件下载
4.苏宁易购某站越权操作及缺陷,其主要原因是没对ID参数做cookie验证导致。
5. 实际上还有很多案例,这里就不一一例举了,但是他们都存在一个共同的特性,就是没有对用户的登陆凭证进行效验,如下图为例。
预防思路
对敏感数据存在的接口和页面做cookie,ssid,token或者其它验证,如下图所示。