netvar1337 业务逻辑漏洞方法论
业务逻辑漏洞的本质是：应用在服务端没有正确校验业务规则，导致攻击者可以通过修改请求参数来违反预期的业务流程。这类漏洞 WAF 和自动化扫描器几乎无法检测——因为每个请求看起来都是"正常"的 HTTP 请求。
Phase 0: 攻击面识别
先通读应用功能，找到所有涉及"状态变化"或"价值转移"的操作：
| 功能类型 | 关注点 | 典型漏洞 |
|---|---|---|
| 支付/购买 | price/amount/total 参数 | 金额篡改、0元购、负数退款 |
| 优惠券/促销 | coupon/promo/discount | 复用、枚举、叠加 |
| 积分/余额 | points/balance/credits | 负数充值、并发消费 |
| 订单流程 | order_id/status/step | 状态跳转、重复操作 |
| 短信/邮箱验证 | phone/email/code | 轰炸、爆破、绕过 |
| 密码重置 | token/code/user_id | 任意用户重置 |
| 用户注册 | role/type/is_admin | 角色注入（→ privilege-escalation-web） |
| 文件/资源操作 | file_id/doc_id | 越权访问（→ idor-methodology） |
Phase 1: 支付与交易
1.1 金额篡改
拦截支付请求，修改 price/amount/total 参数：
原始: POST /api/pay {"order_id":"123","amount":9999}
测试: POST /api/pay {"order_id":"123","amount":1}
测试: POST /api/pay {"order_id":"123","amount":0}
测试: POST /api/pay {"order_id":"123","amount":-1}
测试: POST /api/pay {"order_id":"123","amount":0.01}
重点检查：
- 服务端是否用客户端传来的金额，还是从数据库查询商品价格
- 负数金额是否会导致退款到账户余额
- 小数精度问题（0.001 元能否通过校验）
1.2 数量篡改
原始: {"product_id":"A","quantity":1,"price":100}
测试: {"product_id":"A","quantity":0,"price":100} → 0元购？
测试: {"product_id":"A","quantity":-1,"price":100} → 退款？
测试: {"product_id":"A","quantity":99999,"price":100} → 溢出？
1.3 订单状态篡改
正常流程: 待支付(0) → 已支付(1) → 已发货(2) → 已完成(3)
攻击: 直接发 status=1 跳过支付
攻击: 已完成后再发 status=0 重新获取商品
攻击: 修改其他用户的订单状态
1.4 支付回调伪造
第三方支付（支付宝/微信/Stripe）回调通常是 POST 到应用的 notify_url：
- 检查回调是否验证签名
- 是否可以修改
total_amount字段 - 是否可以重放回调请求（重复到账）
- 是否可以用测试环境的支付结果通知正式环境
Phase 2: 优惠券与积分
2.1 优惠券滥用
# 同一优惠码多次使用
POST /api/coupon/apply {"code":"SAVE50"} → 重复发送
# 优惠码枚举（如果格式可预测）
PROMO001, PROMO002, PROMO003...
# 多优惠券叠加
POST /api/coupon/apply {"codes":["SAVE50","WELCOME20"]}
# 负折扣
POST /api/coupon/apply {"discount":-100}
2.2 积分/余额操作
# 转账负数
POST /api/transfer {"to":"victim","amount":-100}
# 并发充值竞争 → 与 race-condition-exploit 配合
# 积分兑换精度问题（取整方向是否可利用）
Phase 3: 验证码与认证
3.1 短信验证码
# 短信轰炸：同一号码无频率限制
# 验证码爆破：4-6 位数字穷举
# 验证码复用：验证成功后 code 未失效
# 验证码泄露：响应中返回了 code
# 手机号参数污染：
POST /api/sms/send {"phone":["13800138000","attacker_phone"]}
3.2 密码重置漏洞
# 任意用户密码重置 — 修改 user_id/email
POST /api/reset {"token":"valid_token","user_id":"victim_id","password":"hacked"}
# Host 头注入 — 重置链接指向攻击者域名
POST /api/forgot Host: evil.com {"email":"victim@target.com"}
3.3 登录逻辑
# 账户锁定绕过 — 大小写/空格/unicode 变体
# 响应差异枚举 — "用户名不存在" vs "密码错误"
Phase 4: 流程跳过
4.1 多步骤操作跳过
正常: Step1(填信息) → Step2(验证) → Step3(提交)
攻击: 直接请求 Step3 的 API，跳过验证步骤
4.2 前端校验绕过
所有前端校验都可通过抓包绕过——价格只读字段、按钮 disabled、下拉限制选项。
通用测试清单
✅ 所有价格/金额参数: 改为 0、负数、极大值、小数
✅ 所有数量参数: 改为 0、负数、极大值
✅ 所有状态参数: 尝试跳转、回退、重复
✅ 所有 ID 参数: 替换为其他用户/订单的 ID (→ IDOR skill)
✅ 所有验证码: 复用、爆破、轰炸
✅ 所有优惠券: 复用、枚举、叠加
✅ 所有多步骤操作: 跳过中间步骤
✅ 并发请求: 余额消费、优惠券使用 (→ race-condition skill)
深入参考
- 业务逻辑缺陷模式速查（支付/2FA/CAPTCHA/速率限制/注册/密码重置） → references/logic-flaw-patterns.md