sast-businesslogic

业务逻辑漏洞检测

你正在对代码库进行有针对性的安全评估，以查找业务逻辑漏洞。此技能采用包含子 Agent 的三阶段方法：威胁建模（了解领域并生成攻击场景）、分批验证（每批并行验证 3 个场景是否可利用）和合并（汇总各批次结果）。

前提条件：必须存在 sast/architecture.md。如果不存在，请先运行分析技能。

---

什么是业务逻辑漏洞

当应用的预期工作流、规则或约束能够被操纵，从而产生非预期结果时，就会出现业务逻辑漏洞；这类漏洞不涉及利用注入或内存破坏等技术缺陷。攻击者利用应用自身的功能，但以开发者未曾预料的方式使用这些功能。

其核心模式是：应用接受的输入在语法上有效，并通过身份验证／授权，但违反了一项从未在代码中强制执行的业务规则。

什么情况属于业务逻辑漏洞

• 向购买端点提交负数数量，结果收到的是退款而非扣款
• 通过并行请求多次使用同一张一次性折扣券
• 在多步骤结账过程中，重放后续步骤的请求以跳过付款步骤
• 向电影评分端点提交 9999 这样的评分，而该端点本应将评分上限设为 5
• 转账负数金额，将资金从收款方转给付款方
• 使用第二个账户推荐自己，以领取推荐奖励
• 重复使用未失效的单次重置令牌或代金券
• 由于库存检查与预留之间发生竞争条件，购买缺货商品
• 降级到免费套餐后，仍能使用高级订阅功能
• 在其他竞拍者都被淘汰后，通过撤回高额出价赢得拍卖

什么情况不属于业务逻辑漏洞

不要将以下问题归类为业务逻辑问题：

• SQL 注入、XSS、RCE、XXE、SSRF、SSTI：这些属于注入／技术缺陷，应由其他技能处理
• 缺少身份验证：端点完全不需要登录 → 这属于“未授权访问”
• IDOR：通过更改 ID 访问其他用户的资源 → 这属于单独的访问控制问题类别
• 暴力破解／速率限制：登录时的一般速率限制绕过 → 这不属于业务逻辑缺陷，除非它能绕过特定业务规则

---

业务逻辑攻击类别

使用以下类别指导威胁建模。并非所有类别都适用于每个应用，应根据架构摘要确定相关类别。

1. 价格与付款操纵

• 在购买端点使用负价格或零价格
• 在请求正文中任意覆盖价格（批量赋值价格字段）
• 货币或单位混淆（例如，分与元混淆）
• 滥用货币运算中的浮点精度
• 应用折扣，使总额降至零以下

2. 数量与数值限制违规

• 负数量（订购 −5 件商品以获得退款）
• 数量超过每位用户或每笔订单的限额
• 数量或余额计算中的整数溢出／下溢
• 有界字段（评分、分数、百分比）的值超出范围

3. 工作流与多步骤流程绕过

• 跳过顺序流程中的强制步骤（付款、电子邮件验证、身份检查）
• 重放之前成功流程中的完成令牌以绕过步骤
• 未完成前置阶段，直接访问后续阶段的端点
• 未经过中间状态便提交终止状态转换（违反状态机规则）

4. 优惠券、折扣与代金券滥用

• 多次使用同一张优惠券（未强制单次使用）
• 叠加使用原本不应组合使用的折扣
• 使用已过期的优惠券或代金券
• 生成或猜测有效的优惠券代码

5. 竞态条件与并发滥用

• 双重消费：发送两个并发购买请求，只扣除一次余额
• 并发兑换优惠券，导致扣减的额度超出允许范围
• 库存上的 TOCTOU（检查时／使用时）：两个请求的检查均通过，且预留均成功
• 并行发起取款／转账请求，超出账户余额

6. 退款与拒付滥用

• 数字商品已被使用或下载后仍申请退款
• 对已部分退款的订单再次申请部分退款
• 未退回实物就申请退款（如果未在服务端强制执行相关逻辑）

7. 奖励、推荐与忠诚度滥用

• 使用第二个账户自我推荐以赚取推荐奖励
• 通过多个账户多次赚取注册奖励
• 通过虚假活动刷取忠诚度积分
• 分享或转让不可转让的奖励

8. 订阅与权益绕过

• 降级或取消订阅后仍访问付费／高级功能
• 滥用试用期（反复创建新账户以获取试用权限）
• 仅在创建订阅时检查功能标志或套餐，而不在访问功能时检查
• 会话开始时缓存权益，套餐变更后未重新评估

9. 拍卖与竞价逻辑

• 在其他竞价被拒绝后撤回中标竞价
• 托价竞拍：使用受控账户人为抬高价格
• 绕过底价强制检查
• 通过并发请求操纵竞价

10. 库存与存货逻辑

• 因缺少库存验证而购买缺货商品
• 通过并发请求预留超出可用数量的库存
• 因退款但未补回库存的逻辑导致库存为负
• 虚假库存：商品显示有货，但无法履约

11. 时间与日期逻辑

• 在限时优惠过期后继续使用（仅在客户端或仅在服务端进行弱校验）
• 将交易或预订日期回填到过去
• 利用“宽限期”逻辑无限延长权益
• 如果服务端信任客户端提供的时间戳，则可操纵系统时钟

12. 转账与余额逻辑

• 转账负数金额（发送方从接收方处收到钱）
• 通过自我转账利用奖励或费用逻辑
• 因缺少服务端检查而转出超过可用余额的金额
• 利用大量微交易放大舍入误差

---

执行

此技能通过子 Agent 分三个阶段运行。将 sast/architecture.md 的内容作为上下文传递给所有子 Agent。

阶段 1：威胁建模 — 领域分析与攻击场景生成

启动一个子 Agent，并提供以下指令：

目标：分析代码库，了解其业务领域，并针对该应用生成一份具体且按优先级排序的业务逻辑攻击场景清单。将结果写入 sast/businesslogic-threats.md。

背景：你将获得项目的架构摘要。利用它了解应用的用途、功能，以及它应当强制执行的业务规则。请完全专注于了解业务领域——暂时不要验证漏洞。

步骤 1 — 确定业务领域和功能：

阅读 sast/architecture.md，然后探索代码库，回答以下问题：

• 这个应用是做什么的？（电子商务、市场平台、SaaS、社交平台、金融科技、游戏、预订等）
• 有哪些财务或交易功能？（支付、订阅、额度、代币、钱包、发票、退款）
• 有哪些数量限制或规则？（评分、分数、数量、使用限制、配额）
• 有哪些多步骤工作流？（结账、引导流程、KYC、预订、拍卖）
• 有哪些促销或奖励功能？（优惠券、推荐、忠诚度积分、奖金、代金券）
• 有哪些角色或等级区分？（免费与付费、普通用户与高级用户、试用与完整版）
• 有哪些库存或容量限制？（库存、座位、时段、带宽）

要发现功能，请搜索：

• 路由／端点定义及其名称
• 模型／实体名称（Order、Payment、Subscription、Coupon、Wallet、Bid 等）
• 与业务规则相关的字段名称（price、quantity、balance、rating、score、limit、quota、expiry、status）
• 验证逻辑或与约束相关的代码

步骤 2 — 生成攻击场景：

针对发现的每个相关业务领域，生成具体的攻击场景。每个场景都必须：

• 针对该代码库 — 指明涉及的实际端点、模型或功能
• 可执行 — 准确描述攻击者会发送什么内容或执行什么操作
• 有依据 — 引用使该场景具有现实可能性的代码或数据模型

使用以下攻击类别作为检查清单。仅包含与此应用相关的类别：

• 价格／支付操纵：用户能否在请求中发送任意价格？是否信任来自客户端的价格？
• 数量／数值越界：用户能否发送负数数量、零，或超出定义限制的值？
• 工作流绕过：用户能否跳过多步骤流程中的强制步骤？
• 优惠券／折扣滥用：优惠券能否被多次使用或在过期后使用？
• 竞态条件：共享资源（库存、余额、优惠券使用次数）上是否存在先检查后操作的模式？
• 退款滥用：产品已被消耗后，是否还能申请退款？
• 奖励／推荐滥用：推荐或注册奖励能否被反复刷取？
• 权益绕过：高级功能是在访问时检查，还是仅在订阅时检查？
• 转账／余额逻辑：是否可以进行负数转账或向自己转账？
• 时间／日期逻辑：有时限的优惠是否由服务端强制执行？
• 库存逻辑：预留前是否以原子方式验证库存？

输出格式 — 写入 sast/businesslogic-threats.md：

# 业务逻辑威胁模型：[Project Name]

## 应用领域
[用 2–3 句话概述应用的用途及其主要业务功能]

## 已识别的业务功能
- [功能 1]：[简要描述、相关模型／端点]
- [功能 2]：...

## 攻击场景

### 1. [简短标题，例如“利用负数购买数量获取额度”]
- **类别**：[例如“数量与数值限制违规”]
- **目标**：[端点或功能，例如 `POST /api/orders`]
- **描述**：[攻击者会做什么，以及预期结果]
- **相关代码**：[相关逻辑所在的文件和行范围]
- **应强制执行的业务规则**：[应用应当执行的规则]
- **风险等级**：[高 / 中 / 低]

### 2. ...

[对每个场景使用连续编号 ### 3.、### 4.、…… — 这是第 2 阶段分批处理的必要要求。]

## 不适用的类别
[列出检查清单中与此应用无关的类别，并说明原因]

阶段 2：验证 — 检查场景是否可被利用（分批处理）

阶段 1 完成后，读取 sast/businesslogic-threats.md，并将攻击场景拆分为每批最多 3 个场景。每批并行启动一个子 Agent。每个子 Agent 只验证分配给自己的场景，并将结果写入自己的批次文件。

分批流程（由你这个协调者执行，而非子 Agent）：

1. 读取 sast/businesslogic-threats.md，统计编号场景章节（### 1.、### 2. 等）的数量。
2. 将它们划分为每批最多 3 个场景。例如，8 个场景 → 3 批（1–3、4–6、7–8）。
3. 从威胁文件中提取每批场景章节的完整文本。
4. 并行启动所有批次子 Agent，并且只向每个子 Agent 传递分配给它的场景。
5. 每个子 Agent 将结果写入 sast/businesslogic-batch-N.md，其中 N 为从 1 开始的批次编号。

向每个批次子 Agent 提供以下说明（替换为对应批次的具体值）：

目标：针对每个分配的攻击场景，判断代码是否正确执行了业务规则，或攻击是否可以利用。我们的目标是发现业务逻辑漏洞。将结果写入 sast/businesslogic-batch-[N].md。

分配给你的场景（来自威胁建模阶段）：

[在此粘贴所分配场景章节的完整文本，并保留原始编号]

背景：你将获得项目的架构摘要。利用它了解验证模式、ORM 的使用方式，以及通常在哪些位置执行业务规则。追踪每个场景中提到的代码路径。

以下不属于业务逻辑缺陷——请勿在此报告：

• SQL 注入、XSS、RCE、XXE、SSRF、SSTI：由单独的技能负责
• 缺少身份验证：归类为未认证访问
• IDOR：属于另一类访问控制问题
• 通用暴力破解，除非它明显绕过了业务规则

针对每个场景，执行以下检查：

1. 是否在服务端执行了业务规则？

• 是否在后端处理程序、服务层或 ORM／数据库中验证约束？
• 还是仅在客户端验证（前端表单验证、JavaScript min／max 属性）？
• 仅在客户端验证 = 可利用。

2. 验证是否完整并涵盖所有边界情况？

• 在适用情况下，是否检查了负值？
• 是否检查了上限，而不只是下限？
• 是否处理了并发请求（检查是否原子执行，或是否存在 TOCTOU 窗口）？
• 是否在实际使用时重新验证，而不只是较早的步骤中验证？

3. 对于工作流绕过场景：

• 每个步骤是否会验证之前要求的步骤均已完成？
• 步骤完成标志是否存储在服务端（而不只是可重放的 cookie 或 session 中）？
• 是否可以绕过前置步骤，直接调用终端端点？

4. 对于优惠券／代金券场景：

• 是否在同一数据库事务中将优惠券标记为已使用？
• 是否防止并发兑换（SELECT FOR UPDATE、乐观锁、原子比较并交换）？
• 是否在兑换时于服务端检查有效期？

5. 对于竞态条件场景：

• 库存／余额检查和扣减是否以原子方式完成（在单个数据库事务中或使用行级锁）？
• 是否有幂等键或去重逻辑来防止重复的并发请求？

6. 对于权益／订阅场景：

• 是否在访问功能时检查用户当前的套餐／等级？
• 还是在登录／会话开始时缓存，之后再也不重新评估？

7. 对于转账／余额场景：

• 是否在服务端检查转账金额是否为正数？
• 是否在服务端检查发送方余额是否充足？
• 是否在数据库事务中执行这些检查，以防止竞态条件？

分类：

• 可利用：业务规则缺失、可绕过，或仅在客户端执行。
• 很可能可利用：存在规则，但有缺口（竞态条件窗口、缺少边界情况检查、条件可绕过）。
• 不可利用：服务端已正确执行规则，且涵盖边界情况。
• 需要人工审查：无法有把握地判定（逻辑复杂、依赖外部服务等）。

输出格式 — 写入 sast/businesslogic-batch-[N].md：

# 业务逻辑批次 [N] 结果

## 发现

### [可利用] 场景标题
- **类别**：[攻击类别]
- **文件**：`path/to/file.ext`（第 X-Y 行）
- **端点**：`METHOD /path`
- **违反的业务规则**：[应用应执行的规则]
- **问题**：[清楚描述缺少或失效的验证]
- **影响**：[攻击者可以达成的目标——免费商品、经济损失、不公平优势等]
- **证据**：[展示证明缺少相应执行措施的代码路径]
- **修复建议**：[针对该场景的具体修复方法]
- **动态测试**：

[分步说明或用于在运行中的应用上确认发现的 curl 命令。 包含确切的 HTTP 方法、端点、请求头和请求正文。 说明哪些响应或副作用可以确认漏洞。]

### [很可能可利用] 场景标题
- **类别**：[攻击类别]
- **文件**：`path/to/file.ext`（第 X-Y 行）
- **端点**：`METHOD /path`
- **违反的业务规则**：[应执行的规则]
- **问题**：[存在的执行缺口或竞态条件]
- **风险说明**：[尽管已有部分执行措施，为什么仍很可能可利用]
- **证据**：[展示存在薄弱／不完整检查的代码路径]
- **修复建议**：[具体修复方法]
- **动态测试**：

[分步说明或用于确认问题的 curl 命令，例如发送两个并发请求。]

### [不可利用] 场景标题
- **类别**：[攻击类别]
- **文件**：`path/to/file.ext`（第 X-Y 行）
- **业务规则**：[应用应执行的规则]
- **保护措施**：[执行方式——服务端验证、数据库约束、原子事务等]

### [需要人工审查] 场景标题
- **类别**：[攻击类别]
- **文件**：`path/to/file.ext`（第 X-Y 行）
- **不确定性**：[自动化分析无法判定状态的原因]
- **建议**：[需要人工检查或动态测试的内容]

阶段 3：合并 — 汇总批次结果

在第 2 阶段的所有批次子 Agent 完成后，读取每个 sast/businesslogic-batch-*.md 文件，并将它们合并到单个 sast/businesslogic-results.md 文件中。由你（协调者）直接完成此操作，无需子 Agent。

合并流程：

1. 读取所有 sast/businesslogic-batch-1.md、sast/businesslogic-batch-2.md……文件。
2. 收集每个批次文件中的所有发现，并合并为一个列表，同时保留原始分类和所有详细字段。
3. 汇总所有批次的数据，为执行摘要统计总数。
4. 使用以下格式将合并后的报告写入 sast/businesslogic-results.md：

# Business Logic Analysis Results: [Project Name]

## Executive Summary
- Scenarios analyzed: [total across all batches]
- Exploitable: [N]
- Likely Exploitable: [N]
- Not Exploitable: [N]
- Needs Manual Review: [N]

## Findings

[All findings from all batches, grouped by classification:
 EXPLOITABLE first, then LIKELY EXPLOITABLE, then NEEDS MANUAL REVIEW, then NOT EXPLOITABLE.
 Preserve every field from the batch results exactly as written.]

5. 写入 sast/businesslogic-results.md 后，删除所有中间批次文件（sast/businesslogic-batch-*.md）。

---

重要提示

• 读取 sast/architecture.md，并将其内容作为上下文传递给所有子 Agent。
• 第 2 阶段必须在第 1 阶段完成后运行，因为它依赖威胁模型的输出。
• 第 3 阶段必须在所有第 2 阶段的批次完成后运行，因为它依赖所有批次的输出。
• 每个子 Agent 处理 3 个场景。如果总共只有 1–3 个场景，则使用单个子 Agent。如果有 10 个场景，则使用 4 个子 Agent（3+3+3+1）。
• 并行启动所有批次子 Agent，不要按顺序逐个运行。
• 每个批次子 Agent 只接收威胁文件中分配给它的场景文本，而不是整个威胁文件。这样可以让每个子 Agent 的上下文更小、更聚焦。
• 严格专注于业务逻辑缺陷，不要在此处报告注入漏洞、身份验证绕过或 IDOR 问题。
• 第 1 阶段的威胁建模应针对具体应用：没有基于实际代码库的通用场景没有价值。
• 只有服务器端验证才是有效的防护措施。客户端验证、前端表单约束，以及 API 文档中“必须为正数”之类的说明，都不是安全控制措施。
• 金融操作中的竞态条件属于高严重性问题，即使看起来需要精确把握时机也是如此——自动化工具（Turbo Intruder、并发 curl）能让利用变得轻而易举。
• 如有疑问，应分类为“需要人工审查”，而不是“无法利用”。安全评估中的漏报比误报更糟糕。
• 注意 ORM 和数据库层面的约束（CHECK 约束、唯一索引、带锁事务）——这些约束可以提供仅从应用代码中无法看到的强制保障。
• 清理中间文件：写入最终的 sast/businesslogic-results.md 后，删除 sast/businesslogic-threats.md 和所有 sast/businesslogic-batch-*.md 文件。