wgpsec/business-logic-attack

业务逻辑漏洞方法论

业务逻辑漏洞的本质是：应用在服务端没有正确校验业务规则，导致攻击者可以通过修改请求参数来违反预期的业务流程。这类漏洞 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":"[email protected]"}

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