name: business-logic-analysis description: "业务逻辑分析方法论。在 Phase 1 功能分析阶段使用。用于理解 Web 应用业务模型、关键流程、状态流转、金额/数量/优惠券/订单/审批/邀请/积分/库存/支付回调等高价值逻辑入口，并把每个流程转化为可测试的业务漏洞假设。" priority: 8 vuln_types:

• 业务逻辑漏洞
• 流程绕过
• 状态机绕过
• 优惠券滥用

triggers:

• price
• amount
• quantity
• coupon
• discount
• order
• pay
• payment
• refund
• balance
• points
• inventory
• status
• state
• approve
• invite
• workflow

synonyms:

• business logic
• logic flaw
• workflow bypass
• price tampering
• payment logic
• coupon abuse
• 逻辑漏洞
• 业务漏洞

metadata: version: "1.0.0" tags: "业务逻辑,分析,理解,业务流程,攻击面,功能点,优先级" category: "recon" authority: "expert"

业务逻辑分析方法论

0. 立即执行摘要：所有金额、状态、次数、归属、流程顺序都要建漏洞假设

看到 price、amount、quantity、coupon、balance、points、status、state、step、approve、refund、invite、inventory、pay、callback 时，必须进入本 skill。业务逻辑漏洞不是靠 payload，而是靠打破开发者默认假设：用户会按顺序操作、不会改金额、不会重复提交、不会跨账号使用资源、不会伪造回调。

优先顺序：

1. 梳理正常流程和状态机，标出每一步由前端传还是后端算。
2. 找金额、数量、折扣、积分、库存、状态、归属、审批、回调等可信边界。
3. 对每一步测试跳步、逆序、重复、并发、过期重放、跨账号、跨租户。
4. 用无害测试资源验证，不破坏真实支付、提现、订单、库存。

1. 业务入口触发矩阵

核心：先理解再攻击

逻辑漏洞的本质是"开发者认为用户不会这么做，但攻击者偏要这么做"。

你不理解正常流程，就不知道哪里可以"不正常"。

Step 1: 应用类型识别

拿到爬取结果后，先判断这是什么类型的应用：

Step 2: 关键业务流程梳理

对每种应用类型，梳理核心业务流程：

用户生命周期

注册 → 登录 → 使用功能 → 修改信息 → 注销
每一步都要问：
- 注册时有没有邀请码/角色选择？能不能注册成管理员？
- 登录后 Token 怎么发的？有没有过期？
- 修改信息时服务端校验了什么？
- 注销后 Token 还能用吗？

交易流程（电商/支付类最关键）

浏览商品 → 加购物车 → 填地址 → 选支付 → 确认下单 → 支付 → 完成
每一步都要问：
- 价格在哪一步确定？是前端传的还是后端算的？
- 数量有没有上限/下限？负数呢？
- 优惠券在哪一步生效？能叠加吗？
- 订单状态流转是否可以跳步？
- 支付回调是否可以伪造？

权限模型

普通用户 → VIP → 管理员 → 超级管理员
问：
- 不同角色能访问哪些 API？有没有遗漏的权限校验？
- 角色信息存在哪里？Cookie/JWT/Session？能改吗？
- 有没有隐藏的管理端点？

Step 3: 功能点分类与优先级

优先级判断标准

Critical（必测）：

• 涉及钱的操作：支付、充值、提现、转账、退款
• 涉及权限的操作：角色切换、权限分配、管理功能
• 涉及大量用户数据：用户列表、订单导出、数据查询

High（重点测）：

• 参数中有 ID 的 API：user_id、order_id、file_id → IDOR
• 参数中有金额的 API：price、amount、quantity → 篡改
• 有 JWT/Token 的功能：认证绕过、Claims 篡改
• 文件上传/下载：上传绕过、任意文件读取

Medium（常规测）：

• 搜索功能 → 注入
• 个人信息修改 → CSRF、越权
• 评论/消息 → XSS
• 密码重置 → 逻辑绕过

Low（快速过）：

• 静态页面（关于我们、帮助文档）
• 纯展示功能（无交互）

Step 4: API 参数分析

对每个发现的 API，分析其参数的安全含义：

Step 5: 输出测试计划

分析完成后，输出结构化的测试计划：

功能点: 下单支付
优先级: critical
相关 API:
  - POST /api/order/create (参数: product_id, quantity, price, coupon_code)
  - POST /api/order/pay (参数: order_id, amount, payment_method)
  - GET /api/order/detail?order_id=xxx
测试方向:
  1. 金额篡改：修改 create 请求中的 price 参数
  2. 数量篡改：quantity 设为 0 或负数
  3. 优惠券复用：同一 coupon_code 多次使用
  4. 订单越权：改 order_id 查看他人订单 (→ idor-methodology)
  5. 竞态条件：并发支付请求 (→ race-condition-exploit)
  6. 支付状态跳转：直接调用已支付接口

最低必测自检

标记业务分析完成前必须确认：

1. 已识别核心业务流程、状态流转和每一步的服务端校验点。
2. 已标记所有金额、数量、优惠、积分、库存、订单、审批、回调、邀请类参数。
3. 已为每个高价值流程给出跳步、逆序、重复、并发、跨账号、过期重放测试方向。
4. 已说明哪些测试因安全边界只能做无害验证或需要授权。

输出格式

[业务逻辑分析]
功能/流程：
正常状态流：
高价值参数：price/amount/quantity/coupon/status/order_id/user_id/callback/其他
信任边界：前端传入/服务端计算/第三方回调/异步任务/未知
候选漏洞：金额篡改/流程绕过/重复提交/竞态/越权/回调伪造/优惠滥用
建议测试：
安全边界：测试账号/测试订单/禁止真实支付/其他
优先级：Critical/High/Medium/Low