| 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 | {"tags":"业务逻辑,分析,理解,业务流程,攻击面,功能点,优先级","category":"recon","authority":"expert"} |
业务逻辑分析方法论
0. 立即执行摘要：所有金额、状态、次数、归属、流程顺序都要建漏洞假设
看到 price、amount、quantity、coupon、balance、points、status、state、step、approve、refund、invite、inventory、pay、callback 时，必须进入本 skill。业务逻辑漏洞不是靠 payload，而是靠打破开发者默认假设：用户会按顺序操作、不会改金额、不会重复提交、不会跨账号使用资源、不会伪造回调。
优先顺序：
- 梳理正常流程和状态机，标出每一步由前端传还是后端算。
- 找金额、数量、折扣、积分、库存、状态、归属、审批、回调等可信边界。
- 对每一步测试跳步、逆序、重复、并发、过期重放、跨账号、跨租户。
- 用无害测试资源验证，不破坏真实支付、提现、订单、库存。
1. 业务入口触发矩阵
| 入口/参数 | 漏洞假设 | 立即测试 |
|---|
price/amount/total | 金额篡改 | 0、1、负数、小数、超大值、前后端金额不一致 |
quantity/count/num | 数量边界 | 0、负数、超库存、并发扣减 |
coupon/discount/promo | 优惠券滥用 | 重复使用、跨账号、叠加、过期仍可用 |
status/state/step | 状态机绕过 | 直接提交终态、跳过审批/支付/验证 |
order_id/pay_id/refund_id | 订单越权/重复支付 | A/B 账号、重复回调、退款重放 |
invite/referral | 邀请奖励滥用 | 自邀请、重复领取、批量注册 |
balance/points/credit | 资产篡改 | 并发领取、负数扣减、重复兑换 |
callback/webhook/notify | 回调伪造 | 签名弱、状态跳转、重放旧回调 |
核心：先理解再攻击
逻辑漏洞的本质是"开发者认为用户不会这么做，但攻击者偏要这么做"。
你不理解正常流程，就不知道哪里可以"不正常"。
Step 1: 应用类型识别
拿到爬取结果后，先判断这是什么类型的应用：
| 类型 | 特征 | 核心攻击面 |
|---|
| 电商/商城 | 商品列表、购物车、下单、支付 | 金额篡改、订单状态跳转、优惠券滥用 |
| 社交/社区 | 用户主页、关注、消息、动态 | 越权查看私信、身份冒用、隐私泄露 |
| 管理后台 | 用户管理、角色权限、数据看板 | 垂直越权、未授权访问、批量导出 |
| SaaS 平台 | 多租户、工作空间、API Key | 租户隔离突破、API Key 泄露 |
| 金融/支付 | 充值、提现、转账、钱包 | 竞态条件双花、金额溢出、提现逻辑 |
| 内容平台 | 文章、评论、上传、搜索 | XSS、SSRF（图片加载）、文件上传 |
| API 服务 | RESTful/GraphQL、文档、SDK | 未授权端点、批量查询、注入 |
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，分析其参数的安全含义：
| 参数模式 | 含义 | 测试方向 |
|---|
user_id=1001 | 用户标识，连续整数 | IDOR：改成 1002 |
order_id=ORD20240001 | 订单号，有规律 | IDOR：遍历 |
price=9900 | 金额（分） | 改为 1、0、-1 |
role=user | 角色字段 | 改为 admin |
is_admin=false | 权限标志 | 改为 true |
redirect=https://a.com | 跳转地址 | SSRF/Open Redirect |
file=report.pdf | 文件名 | 路径穿越 ../../etc/passwd |
token=eyJhb... | JWT | 解码 → 篡改 → 重放 |
callback=handleData | JSONP 回调 | XSS |
xml=<root>... | XML 输入 | XXE |
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. 支付状态跳转：直接调用已支付接口
最低必测自检
标记业务分析完成前必须确认：
- 已识别核心业务流程、状态流转和每一步的服务端校验点。
- 已标记所有金额、数量、优惠、积分、库存、订单、审批、回调、邀请类参数。
- 已为每个高价值流程给出跳步、逆序、重复、并发、跨账号、过期重放测试方向。
- 已说明哪些测试因安全边界只能做无害验证或需要授权。
输出格式
[业务逻辑分析]
功能/流程：
正常状态流：
高价值参数：price/amount/quantity/coupon/status/order_id/user_id/callback/其他
信任边界：前端传入/服务端计算/第三方回调/异步任务/未知
候选漏洞：金额篡改/流程绕过/重复提交/竞态/越权/回调伪造/优惠滥用
建议测试：
安全边界：测试账号/测试订单/禁止真实支付/其他
优先级：Critical/High/Medium/Low
