逻辑漏洞挖掘一直是安全测试中“经久不衰”的话题。相比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或者其它验证，如下图所示。
