写在前面：合法学习边界
业务逻辑测试只允许在自建靶场或授权环境进行。对真实系统篡改支付、刷优惠券可能触犯法律。
一、漏洞原理
业务逻辑漏洞不是技术缺陷，而是业务流程/规则本身没被校验。攻击者不绕防火墙，而是“顺着业务规则钻空子”。
常见形态：
1
2
3
4
5
6
| 支付逻辑：改金额、负数、改数量、改价格参数
验证码：不校验、可重放、前端校验、短信轰炸
优惠券/积分：重复领取、并发领取、越权使用
越权：他人订单/支付操作
重放：同一请求重复生效
并发：同一操作并发执行多次
|
漏洞本质：客户端可影响业务关键参数，服务端没做服务端校验。
二、影响与危害
1
2
3
4
| 资金损失（改价、刷单）
账号/订单被篡改
短信/邮件轰炸
业务数据污染
|
风险等级：高（直接影响钱和业务）。
三、利用 / 复现
支付篡改
1
2
3
| 1. 下单抓包，把 price/amount 改成负数或 0.01
2. 或改数量导致金额异常
3. 观察支付/订单状态
|
重点参数：
1
| price、amount、quantity、total、discount、couponId
|
验证码绕过
1
2
3
4
| 前端校验 → 直接抓包重放
验证码不绑定手机/请求 → 复用
验证码不过期 → 重复使用
短信接口无频率限制 → 轰炸
|
越权与重放
1
2
3
| 改订单/支付单 ID 操作他人订单
同一支付回调重放多次到账
优惠券接口并发请求重复领取
|
复现操作步骤
1
2
3
4
| 第 1 步：抓支付/优惠券/验证码/越权接口
第 2 步：改金额/数量/重放/并发请求
第 3 步：看金额是否变化、是否重复生效 —— 变化即确认
第 4 步：验证码复用、越权 ID 替换测试
|
四、检测
1
2
3
4
| 对订单/支付/优惠/验证码接口做参数篡改测试
并发测试（多请求同时）验证竞态
检查服务端是否信任前端传的价格/角色
对比不同账号的操作边界
|
五、防御
1
2
3
4
5
| 关键金额/数量由服务端计算，不信任前端
验证码绑定会话+有效期+频率限制
接口幂等与去重（订单号、nonce）
并发控制（乐观锁/分布式锁）
所有敏感操作服务端校验权限与归属
|
六、修复
1
2
3
4
| 服务端重算金额，删除可改价格参数
验证码服务端校验并限频
订单支付加唯一约束与回调去重
修复后复测：改价/重放/并发均被拦截
|
七、小结
逻辑漏洞没有“万能 payload”，靠的是理解业务。测试时把每个关键业务流程拆开：参数能不能改、能不能重放、能不能并发、归属有没有校验。它比技术漏洞更考验人。