SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsbusiness-logic-attack

business-logic-attack

General & other

View repository

Updated 10-16 09:52

About this skill

Business Logic Vulnerability Methodology

The essence of business logic vulnerabilities is that the application does not correctly validate business rules on the server side, allowing attackers to violate the expected business process by modifying request parameters. This type of vulnerability is nearly impossible for WAFs and automated scanners to detect—because every request looks like a "normal" HTTP request.

Phase 0: Attack Surface Identification

First read through the application's functionality and find all operations involving "state changes" or "value transfers":

Feature Type Focus Points Typical Vulnerabilities
Payment/Purchase price/amount/total parameters Amount tampering, zero-cost purchase, negative refund
Coupons/Promotions coupon/promo/discount Reuse, enumeration, stacking
Points/Balance points/balance/credits Negative top-up, concurrent spending
Order Process order_id/status/step State transition, repeated operations
SMS/Email Verification phone/email/code Bombing, brute force, bypass
Password Reset token/code/user_id Arbitrary user reset
User Registration role/type/is_admin Role injection (→ privilege-escalation-web)
File/Resource Operations file_id/doc_id Unauthorized access (→ idor-methodology)

Phase 1: Payment and Transactions

1.1 Amount Tampering

Intercept the payment request and modify the price/amount/total parameters:

原始: POST /api/pay {"order_id":"123","amount":9999}
测试: POST /api/pay {"order_id":"123","amount":1}
测试: POST /api/pay {"order_id":"123","amount":0}
测试: POST /api/pay {"order_id":"123","amount":-1}
测试: POST /api/pay {"order_id":"123","amount":0.01}

Key checks:

  • Whether the server uses the amount passed from the client, or queries the product price from the database
  • Whether a negative amount causes a refund to the account balance
  • Decimal precision issues (whether 0.001 yuan can pass validation)

1.2 Quantity Tampering

原始: {"product_id":"A","quantity":1,"price":100}
测试: {"product_id":"A","quantity":0,"price":100}    → 0元购？
测试: {"product_id":"A","quantity":-1,"price":100}   → 退款？
测试: {"product_id":"A","quantity":99999,"price":100} → 溢出？

1.3 Order Status Tampering

正常流程: 待支付(0) → 已支付(1) → 已发货(2) → 已完成(3)
攻击: 直接发 status=1 跳过支付
攻击: 已完成后再发 status=0 重新获取商品
攻击: 修改其他用户的订单状态

1.4 Payment Callback Forgery

Third-party payment (Alipay/WeChat/Stripe) callbacks are usually POSTed to the application's notify_url:

  • Check whether the callback verifies the signature
  • Whether the total_amount field can be modified
  • Whether the callback request can be replayed (duplicate crediting)
  • Whether a payment result notification from the test environment can be used to notify the production environment

Phase 2: Coupons and Points

2.1 Coupon Abuse

# 同一优惠码多次使用
POST /api/coupon/apply {"code":"SAVE50"} → 重复发送

# 优惠码枚举（如果格式可预测）
PROMO001, PROMO002, PROMO003...

# 多优惠券叠加
POST /api/coupon/apply {"codes":["SAVE50","WELCOME20"]}

# 负折扣
POST /api/coupon/apply {"discount":-100}

2.2 Points/Balance Operations

# 转账负数
POST /api/transfer {"to":"victim","amount":-100}

# 并发充值竞争 → 与 race-condition-exploit 配合
# 积分兑换精度问题（取整方向是否可利用）

Phase 3: Verification Codes and Authentication

3.1 SMS Verification Code

# 短信轰炸：同一号码无频率限制
# 验证码爆破：4-6 位数字穷举
# 验证码复用：验证成功后 code 未失效
# 验证码泄露：响应中返回了 code
# 手机号参数污染：
POST /api/sms/send {"phone":["13800138000","attacker_phone"]}

3.2 Password Reset Vulnerabilities

# 任意用户密码重置 — 修改 user_id/email
POST /api/reset {"token":"valid_token","user_id":"victim_id","password":"hacked"}

# Host 头注入 — 重置链接指向攻击者域名
POST /api/forgot  Host: evil.com  {"email":"victim@target.com"}

3.3 Login Logic

# 账户锁定绕过 — 大小写/空格/unicode 变体
# 响应差异枚举 — "用户名不存在" vs "密码错误"

Phase 4: Process Skipping

4.1 Multi-step Operation Skipping

正常: Step1(填信息) → Step2(验证) → Step3(提交)
攻击: 直接请求 Step3 的 API，跳过验证步骤

4.2 Front-end Validation Bypass

All front-end validation can be bypassed through packet capture—read-only price fields, disabled buttons, restricted dropdown options.

General Testing Checklist

✅ 所有价格/金额参数: 改为 0、负数、极大值、小数
✅ 所有数量参数: 改为 0、负数、极大值
✅ 所有状态参数: 尝试跳转、回退、重复
✅ 所有 ID 参数: 替换为其他用户/订单的 ID (→ IDOR skill)
✅ 所有验证码: 复用、爆破、轰炸
✅ 所有优惠券: 复用、枚举、叠加
✅ 所有多步骤操作: 跳过中间步骤
✅ 并发请求: 余额消费、优惠券使用 (→ race-condition skill)

In-depth References