business-logic-testing

业务逻辑测试（发现/利用——专业人士的拿手好戏）

概述

找出应用允许执行的操作中的缺陷，而不是代码编写方式中的问题。这些请求本身有效，却会产生无效结果——以 0 元购买、重复退款、跳过必经步骤。任何扫描器都找不到这些问题，因为它们各自取决于你的业务规则。

**核心原则：**应用会强制执行预期流程；你要测试每一条仍然“可行”的非预期路径。想想：“这个功能依赖什么假设？如果我打破这个假设会怎样？”

适用情况 / 跳过情况

• **适用情况：**应用包含多步骤工作流、资金/积分/配额、有状态流程，或可能被滥用的业务规则。
• **跳过情况：**应用是无状态的单操作工具，没有规则或状态 → N/A（这种情况很少见——大多数应用都有一些逻辑；跳过前请仔细确认）。
• **如果 N/A：**报告“business-logic-testing: N/A — no stateful workflow/rules”并停止。

⚠️ 授权

仅限你自己的应用/测试数据。滥用逻辑可能会转移资金或改变状态——请使用非生产环境。

方法

1. 了解预期流程——梳理各个步骤、规则以及每一步的假设（顺序：添加 → 付款 → 发货；规则：数量 ≥ 1；假设：价格由服务器提供）。
2. 挑战每项假设——尝试负值/零/极大值、跳过步骤、调整步骤顺序、提供本应由服务器掌控的客户端值，以及重复操作。
3. 攻击状态机——以错误顺序到达某些状态，或重新进入终态。
4. 攻击并发——并行多次执行“只能执行一次”的操作（竞态条件/TOCTOU）。
5. 攻击数量与金额——篡改价格、总额、货币、折扣、舍入结果和限额。

具体模式请参阅 references/logic-attack-patterns.md。

快速参考——典型逻辑缺陷

模式	示例
参数篡改	更改服务器信任的请求中的 price、total、qty、userId、status
负数/溢出	qty=-1 会给你增加积分；极大值会溢出；0 可绕过收费
工作流绕过	不经过“付款”/“验证”，直接跳到“确认”/“下载”
状态机滥用	取消已发货的订单；重新打开已关闭的工单以获取权限
竞态条件/TOCTOU	并行兑换同一张礼品卡/优惠券/提现 N 次
重放	重新提交经过签名的/一次性请求（支付回调、OTP、幂等键）
滥用折扣/退款	叠加优惠券、退款金额超过已付款金额、循环申请部分退款
绕过限额	通过并行请求或多个会话突破每用户上限

竞态条件测试（价值高，常被忽略）

同时（而非依次）多次发送“限量”操作，并检查是否成功不止一次——例如，对一张仅可使用一次的优惠券并行兑换 20 次。工具：Burp Turbo Intruder，或用快速并行的 curl/脚本同时发送完全相同的请求。

输出

报告应说明预期规则、破坏该规则的请求以及业务影响（资金损失、绕过限额、获取权限）。严重性 = 实际影响，通常为严重。

后续处理

通过 active-pentest 在预发布环境中安全复现；在 vulnerability-chaining 中与身份验证/访问控制问题串联；通过 security-hardening 修复（由服务器掌控的值、原子事务/锁、幂等键、服务器端状态验证）。

常见错误

• 寻找代码异味——逻辑漏洞存在于有效请求中；你必须了解规则。
• 按顺序测试操作，而漏洞只会在并发情况下出现。
• 信任客户端发送的价格/总额/限额——应在服务器端重新计算所有值，并测试是否确实如此。
• 忽略“软性”功能：优惠券、推荐奖励、忠诚度积分、试用、退款——这些都是滥用的重点目标。