原理
业务逻辑漏洞 是开发业务流程的缺陷 不仅仅限于网络层 系统层 代码层
比如 登录验证码的绕过 交易的数据篡改 接口的恶意调用
目标
购物 社交 p2p o2o 游戏 招聘 只要是在线支付的 主要是经济利益为主
测试
白盒 文档 代码 熟悉系统的业务
黑盒 实操理解业务
业务安全经典场景
一.商品支付金额篡改
1毛钱买电冰箱
漏洞点 用户端和服务端和业务系统接口之间的数据传输 前端传输数据后端没有校验
利用方式
bp抓包 改金额
2.前端js限制绕过
绕过js限制 购买多个打折商品
漏洞点
web应用仅在页面通过js脚本限制 后端也就是服务端校验用户没有校验数量
通过抓取客户端发送的请求包修改JS 端生成处理的交易数据,如将请求中的商品数量改为大于最大数限制的值,查看能否以非正常业务交易数据完成业务流程
3.请求重放漏洞
一次购买 多次收货
电商 一次购买成功 多次使用bp重放 验证交易流程中随机数 时间戳
4.业务上限测试
无限制查询历史消费记录
服务端没有对用户提交的查询范围、订单数量、金额等数据进行严格校验而 引发的一些业务逻辑漏洞
漏洞点 在业务流程中通过向服务端提交高于或低于预期的数据以校验服务端是否对所提交的数据做预期强校验。存在 此类脆弱性的应用程序,通常表现为查询到超出预期的信息、订购或兑换超出预期范围的商品
5.商品订购数量篡改
通过bp抓包 改包订购商品数量 把包改为负数 或者别的 查看业务是不是ok
二.密码找回安全
原理
用户提交修改密码修改
账户认证
身份验证
改密码
1.验证码客户端回显测试
任意用户登录
使用场景
人机验证
原理
查看验证码是不是会回显到响应报文中 如果有则通过 没有则没有
2.验证码暴力破解
验证码无使用次数限制
原理
在测试验证码是否可以被暴力枚举时,可以先将验证码多次发送给自己的账号,观察验证码是否有规律,如每次接收到的验证码为纯数字并且是4 位数。
利用

response状态值修改测试
response状态值修改测试 修改请求的响应结果来达到密码重置目的
存在这种漏洞 检验不合格导致重置密码操作
利用
漏洞的利用方式通常是在服务端发送某个密码重置的凭证请求后,出现特定的响应值
如 true 1 ok success 200
网站看到回显内容为特定值后即修改密码或者登陆,通常这种漏洞的回显值校验是在客户端进行的,所以只需要修改服务器的响应数据包即可。
4.session覆盖