业务逻辑漏洞是什么
逻辑漏洞不依赖代码层面的技术缺陷，而是业务流程被以非预期顺序或组合使用：优惠券重复使用、跳过支付步骤直接发货、负数购买、金额精度差异、并发绕过限额等。它天然躲开扫描器，因为请求本身语法完全合法。防护思路是流程状态机 + 关键数值一律由服务端重算 + 并发场景下的幂等与锁。
基本信息
| 典型入口 | 下单、支付、退款、领券、提现、审批流 |
|---|---|
| 发现方式 | 业务用例评审 + 人工测试（扫描器基本无效） |
| 防护位置 | 服务端流程控制与数值校验 |
| 常见根因 | 信任客户端输入、状态可跳转、缺少幂等 |
典型案例模式
典型案例模式
顺序颠倒：先发货后付款的步骤可被跳过
重复提交：接口无幂等控制（重复领取、重复退款）
数值边界：负数、超大数、精度差异、四舍五入取整
条件竞态：并发请求绕过限额、库存为负
参数越权：只校验格式不校验归属防护设计
防护设计
状态机：订单只能按 待支付→已支付→已发货 迁移，非法跳转直接拒绝
幂等：唯一键 + 状态前置检查，重复请求返回同一结果
金额、库存、优惠一律以服务端计算为准，不信任客户端提交值
限流与分布式锁保护限额类操作
流程节点埋审计日志，事后可还原操作序列典型使用场景
- 电商大促前的用例评审：按「流程能被打乱吗」逐条过关键路径
- 资损事件复盘：从业务流水反推被滥用的字段与接口
- 返利与积分业务：上线前先做并发与边界用例测试
- 风控规则设计：把逻辑滥用特征转成可监控的指标（同账号高频、金额异常）
- 需求评审阶段介入：在状态机设计里就阻断非法迁移，比事后补救便宜
案例到防护的对应关系
| 案例 | 根因 | 防护动作 |
|---|---|---|
| 优惠券重复使用 | 无幂等与状态锁 | 券状态机 + 唯一键 |
| 跳过支付发货 | 状态可任意跳转 | 服务端校验状态迁移顺序 |
| 负数金额购买 | 只校验格式不校验范围 | 服务端做数值范围与净额校验 |
| 并发绕过限额 | 检查与写入非原子 | 加锁或用原子更新语句 |
逻辑漏洞扫描器通常发现不了，需要基于业务做用例评审与人工测试：把「攻击者会怎样滥用这个流程」写成测试用例，比再买一套扫描器更有产出。
幂等键要由服务端下发或校验唯一性，仅靠客户端传入的去重 ID 没有意义——攻击者可以每次换一个。