ineedcodes 1.6.1 → 1.7.0

package/skills/business-logic-vulnerabilities/SKILL.md

@@ -0,0 +1,711 @@
+---
+name: business-logic-vulnerabilities
+description: >-
+  Business logic vulnerability playbook. Use when reasoning about workflows, race conditions, price manipulation, coupon abuse, state machines, and multi-step authorization gaps.gated: true
+---
+
+# SKILL: Business Logic Vulnerabilities — Expert Attack Playbook
+
+> **AI LOAD INSTRUCTION**: Business logic flaws are scanner-invisible and high-reward on bug bounty. This skill covers race conditions, price manipulation, workflow bypass, coupon/referral abuse, negative values, and state machine attacks. These require human reasoning, not automation. For specific exploitation techniques (payment precision/overflow, captcha bypass, password reset flaws, user enumeration), load the companion [SCENARIOS.md](./SCENARIOS.md). For the workflow approach itself (modeling → state machine → attack-surface matrix → human judgement) load [METHODOLOGY.md](./METHODOLOGY.md). For the per-module check items load [CHECKLIST.md](./CHECKLIST.md).
+
+### Companion files
+
+| File | When to load |
+|---|---|
+| [METHODOLOGY.md](./METHODOLOGY.md) | Need the 5-phase workflow, attack-surface 5×N matrix, human-judgement decision tree |
+| [CHECKLIST.md](./CHECKLIST.md) | Going through a target module-by-module (login / register / payment / IDOR / privacy) and want every line item with why+verify |
+| [SCENARIOS.md](./SCENARIOS.md) | Drilling deeper into payment precision/overflow, captcha bypass, password reset, enumeration, frontend bypass |
+
+### Extended Scenarios
+
+Also load [SCENARIOS.md](./SCENARIOS.md) when you need:
+- Payment precision & integer overflow attacks — 32-bit overflow to negative, decimal rounding exploitation, negative shipping fees
+- Payment parameter tampering checklist — price, discount, currency, gateway, return_url fields
+- Condition race practical patterns — parallel coupon application, gift card double-spend with Burp group send
+- Captcha bypass techniques — drop verification request, remove parameter, clear cookies to reset counter, OCR with tesseract
+- Arbitrary password reset — predictable tokens (`md5(username)`), session replacement attack, registration overwrite
+- User information enumeration — login error message difference, masked data reconstruction across endpoints, base64 uid cookie manipulation
+- Frontend restriction bypass — array parameters for multiple coupons (`couponid[0]`/`couponid[1]`), remove `disabled`/`readonly` attributes
+- Application-layer DoS patterns — regex backtracking, WebSocket abuse
+
+---
+
+## 1. PRICE AND VALUE MANIPULATION
+
+### Negative Quantity / Price
+Many applications validate "amount > 0" but not for currency:
+```
+Add to cart with quantity: -1
+Update quantity to: -100
+{
+  "quantity": -5,
+  "price": -99.99     ← may be accepted
+}
+```
+**Impact**: Receive credit to account, items for free, bank transfers in reverse.
+
+### Decimal Quantity — "0元购" Case
+Real instructor-led case: an e-commerce app accepted **fractional `quantity`** because backend trusted client float values:
+```json
+// Cart item:
+{"id": 114016, "skuQty": 0.02}
+// Original price ¥500 → final price ¥10
+// Variant on a food delivery app:
+// FoodNum=0.01 → 68元 商品 实付 0.68元
+```
+Why it works: server multiplies `unit_price * quantity` without enforcing `quantity ∈ Z+`, so a 2% sliver order pays 2% price but ships the full item. Reproduce by intercepting the cart submit → setting `skuQty` / `FoodNum` to `0.02` → finishing checkout.
+
+### Drop a Required Field — Free Tier Coercion
+Sport activity registration: when paid prizes are involved server returns `"payType": "paid"`; if the client request is **edited to omit `prizeIdList` entirely**, the server falls back to `"payType": "free"` and creates a successful registration that should have cost money.
+```json
+// Original
+{"prizeIdList": ["6264e6948fe587000113e2d9"], ...}
+// Modified — array removed entirely
+{"prizeIdList": [], ...}
+// Server response:
+{"ok": true, "payType": "free"}
+```
+This is a parameter-existence trust bug — backend treats "field absent" as "no paid item to enforce", so fix is to require the field and validate its content server-side.
+
+### Integer Overflow
+```
+quantity: 2147483648   ← INT_MAX + 1 overflows to negative in 32-bit
+price: 9999999999999   ← exceeds float precision → rounds to 0
+```
+Real case: setting `amount=999999999` triggered an overflow path where the system stored `0` as final payable. **Always coordinate before triggering overflow tests** — they sometimes crash payment services.
+
+### Rounding Manipulation
+```
+Item price: $0.001
+Order 1000 items → each rounds down → total = $0.00
+```
+Real "half-price recharge" bug: input `¥0.019` to top-up. The pay gateway charges only `¥0.01` (rounded down to the cent), but the wallet credits `¥0.02` (rounded up). Net gain per cycle is `¥0.01`, repeat for free balance growth.
+
+### Currency Exchange Rate Lag
+```
+1. Deposit using currency A at rate X
+2. Rate changes
+3. Withdraw using currency A at new rate → profit from rate difference
+```
+
+### Free Upgrade via Promo Stacking
+Test combining discount codes, referral credits, welcome bonuses:
+```
+Apply promo: FREE50  → 50% off
+Apply promo: REFER10 → additional 10%
+Apply loyalty points → additional discount
+Total: -$5 (free + credit)
+```
+
+---
+
+## 2. RACE CONDITIONS
+
+**Concept**: Two operations run simultaneously before the first completes its check-update cycle.
+
+### Double-Spend / Double-Redeem
+```bash
+# Send same request simultaneously (~millisecond apart):
+# Use Burp Repeater "Send to Group" or Race Conditions tool:
+
+POST /api/use-coupon    ← send 20 parallel requests
+POST /api/redeem-gift   ← same coupon code, parallel
+POST /api/withdraw-funds ← same balance, parallel
+
+# If check and update are non-atomic:
+# Thread 1: check(balance >= 100) → TRUE
+# Thread 2: check(balance >= 100) → TRUE (before Thread 1 deducted)
+# Thread 1: balance -= 100
+# Thread 2: balance -= 100 → BOTH succeed → double-spend
+```
+
+### Race Condition Test with Burp Suite
+```
+1. Capture request
+2. Send to Repeater → duplicate 20+ times
+3. "Send group in parallel" (Burp 2023+)
+4. Check: did any duplicate succeed?
+```
+
+### Turbo Intruder — Bypassing Per-Number SMS Rate Limit
+Real case: when a normal request returns `"该号码短时间内申请发送短信次数过多，拒绝发送"`, sending the **same payload** with high concurrency through Turbo Intruder defeats the simple counter:
+```python
+def queueRequests(target, wordlists):
+    engine = RequestEngine(endpoint=target.endpoint,
+                           concurrentConnections=30,
+                           requestsPerConnection=10,
+                           pipeline=False)
+    for i in range(30):
+        engine.queue(target.req, target.baseInput, gate='race1')
+    engine.openGate('race1')
+```
+Result: the per-phone limiter races and many requests slip through, generating multiple distinct verification codes (a real SMS-bombing case). Root cause: counter increment is non-atomic vs. the read.
+
+### Multi-Device Concurrent VIP Subscription
+Real case: a service offers **first-month-only discount**. Open the pay sheet on multiple devices (A, B, C) before any payment finishes, then complete each in sequence. Server only checks "is new user?" at the **first** request, so all subsequent requests inherit the discount AND the VIP duration stacks.
+```
+Normal: 下单 → 支付 → 充值会员 → 第二次下单 → 服务端校验 "已是新人" → 拒绝
+Bypass: 设备A: 进入支付页 (锁定优惠资格)
+        设备B: 进入支付页 (并发锁定)
+        设备A: 完成支付 → VIP +1月 (优惠价)
+        设备B: 完成支付 → VIP +1月 (仍按优惠价)
+```
+Same trick works on "补差价升级会员" — concurrent top-ups duplicate the duration credit.
+
+### Account Registration Race
+```
+Register with same email simultaneously → two accounts created → data isolation broken
+Password reset token race → reuse same token twice
+Email verification race → verify multiple email addresses
+```
+
+### Limit Bypass via Race
+```
+"Claim once" discounts, freebies, "first order" bonus:
+→ Send 10 parallel POST /claim requests
+→ Race window: all pass the "already claimed?" check before any write
+```
+
+---
+
+## 3. WORKFLOW / STEP SKIP BYPASS
+
+### Payment Flow Bypass
+```
+Normal flow:
+  1. Add to cart
+  2. Enter shipping info
+  3. Enter payment (card/wallet)
+  4. Click confirm → payment charged
+  5. Order confirmed
+
+Attack: Skip to step 5 directly
+POST /api/orders/confirm {"cart_id": "1234", "payment_status": "paid"}
+→ Does server trust client-sent payment_status?
+```
+
+### Multi-Step Verification Skip
+```
+Password reset flow:
+  1. Enter email
+  2. Receive token
+  3. Enter token
+  4. Set new password (requires valid token from step 3)
+
+Attack: Try going to step 4 without completing step 3:
+POST /reset/password {"email": "victim@x.com", "token": "invalid", "new_pass": "hacked"}
+→ Does server check that token was properly validated?
+
+Or: Try token from old/expired flow → still accepted?
+```
+
+### 2FA Bypass
+```
+Normal flow:
+  1. Enter username + password → success
+  2. Enter 2FA code → logged in
+
+Attack: After step 1 success, go directly to /dashboard
+→ Is session created before 2FA completes?
+→ Does /dashboard require 2FA-complete check or just "authenticated" flag?
+```
+
+### Filter Path Truncation Bypass — `..//` and `;`
+
+Real case from a Java Web class audit: a manually-implemented Servlet `Filter` checks login by inspecting the URI string. Two reliable bypasses:
+
+```
+Path-traversal truncation (../):
+  Protected:   http://target/FilterDemo/index.jsp        → 302 to /login
+  Bypass:      http://target/FilterDemo/../../index.jsp  → 200 (filter sees "../../", URL parser collapses)
+
+Semicolon truncation (;):
+  Protected:   http://target/admin/doLogin.action        → 302 to /login
+  Bypass:      http://target/;/admin/doLogin.action      → 200
+                              ^
+                              Servlet container treats segment after ; as "path parameter",
+                              filter that uses request.getRequestURI() sees "/;/admin/doLogin.action",
+                              doesn't match its protected-prefix "/admin/", lets the request through,
+                              but the dispatcher then routes to the real /admin/doLogin.action handler.
+```
+
+**Fix**: never use `request.getRequestURI()` for security checks; use `request.getServletPath()` which is the normalized servlet-mapped path:
+```java
+// Vulnerable
+String uri = request.getRequestURI();   // /;/admin/doLogin.action
+// Safe
+String path = request.getServletPath(); // /admin/doLogin.action
+```
+
+When auditing Java code, grep for `request.getRequestURI()` paired with `Filter`/`startsWith`/`indexOf("/admin")` patterns — those are immediate red flags.
+
+### Real-Name Verification Replay-To-Reset
+
+Fraudulent path that deliberately fails real-name authentication to **reopen** the editing flow:
+```
+1. Submit real-name auth with intentionally wrong cardNumber
+   → server returns "code:200, msg:success, ok:true" but flow shows "驳回 / 等待审核"
+2. Because the server marks state as "rejected" but doesn't lock the user, the UI lets the
+   account go back into the "edit identity" state
+3. Now resubmit with another (possibly stolen) identity
+   → real-name binding repeats indefinitely, defeating anti-addiction lock and enabling account resale
+```
+Defense: rejected real-name submissions must lock the account / require human review, not loop back to the editor.
+
+### Shipping Without Payment
+```
+  1. Add item to cart
+  2. Enter shipping address
+  3. Select payment method (credit card)
+  4. Apply promo code (100% discount or gift card)  
+  5. Final amount: $0
+  6. Order placed
+
+Attack: Apply 100% discount code → no actual payment processed → item ships
+```
+
+---
+
+## 4. COUPON AND REFERRAL ABUSE
+
+### Coupon Stacking
+```
+Test: Can you apply multiple coupon codes?
+Test: Does "SAVE20" + promo stack to >100%?
+Test: Apply coupon, remove item, keep discount applied, add different item
+```
+
+### Referral Loop
+```
+1. Create Account_A
+2. Register Account_B with Account_A's referral code → both get credit
+3. Create Account_C with Account_B's referral code
+4. Ad infinitum with throwaway emails
+→ Infinite credit generation
+```
+
+### Coupon = Fixed Dollar Amount on Variable-Price Item
+```
+Coupon: -$5 off any order
+Buy item worth $3, use -$5 coupon → net -$2 (credit balance)
+```
+
+---
+
+## 5. ACCOUNT / PRIVILEGE LOGIC FLAWS
+
+### Email Verification Bypass
+```
+1. Register with email A (legitimate, verified)
+2. Change email to B (attacker's email, unverified)
+3. Use account as verified — does server enforce re-verification?
+
+Or: Change email to victim's email → no verification → account claim
+```
+
+### Password Reset Token Binding
+```
+1. Request password reset for your account → get token
+2. Change your email address (account settings)
+3. Reuse old password reset token → does it still work for old email?
+
+Or: Request reset for victim@target.com
+    Token sent to victim but check: does URL reveal predictable token pattern?
+```
+
+### OAuth Account Linking Abuse
+```
+1. Have victim's email (but not their password)
+2. Register with victim's email → get account with same email
+3. Link OAuth (Google/GitHub) to your account
+4. Victim logs in with Google → server finds email match → merges with YOUR account
+```
+
+### Cookie Replacement — Horizontal/Vertical Privilege Escalation
+
+The textbook IDOR demo from the audit videos:
+```
+1. Login as super-admin → capture request, copy Cookie (JSESSIONID/Token)
+2. Logout, login as plain user → capture another request to the SAME endpoint
+3. Replay the plain-user request, but swap the Cookie value with the admin's token
+4. If the response returns admin-only data → vertical escalation
+   If it returns another-user's data → horizontal escalation
+```
+A common companion bug: `/oa/emp/list` returns **HTTP 302 to /login when no cookie**, but **200 with full data when any plain-user cookie is sent** — meaning the only check is "logged in?", not "authorized for this endpoint".
+
+### Permission Residue from Database Inconsistency
+
+A subtle case from the second audit class: the admin UI shows that role X has had permission `user:list` revoked, but querying the SQL data:
+
+```sql
+SELECT * FROM sys_menu WHERE role_id = 2;
+-- two rows for the same menu_id "user:list"
+```
+
+The UI's "remove permission" only deleted ONE row; the duplicate row keeps the API accessible. Verify by:
+```sql
+SELECT menu_id, COUNT(*) FROM sys_menu GROUP BY menu_id, role_id HAVING COUNT(*) > 1;
+```
+
+Lesson: when a UI says permission revoked but API still works → check the underlying RBAC table for duplicates / orphaned grants.
+
+### Weak-Random Password Reset Token
+
+PHP / legacy stack on Windows uses `rand()` whose `RAND_MAX = 32768`. If a reset link uses
+`/resetpassword.php?id=md5(rand())`, the entire keyspace is precomputable:
+```php
+$a = 0;
+for ($a = 0; $a <= 32768; $a++) {
+    $b = md5($a);
+    echo $b . "\r\n";
+}
+```
+Iterate the resulting dictionary against `/resetpassword.php?id=<hash>` — when one returns a valid reset page you can change the victim's password. Audit any token generation that ultimately calls `rand()`, `mt_rand()` (without seeding), `Random()` (default seed in C#), etc.
+
+---
+
+## 6. API BUSINESS LOGIC FLAWS
+
+### Object State Manipulation
+```
+order.status = "pending"
+→ PUT /api/orders/1234 {"status": "refunded"}   ← self-trigger refund
+→ PUT /api/orders/1234 {"status": "shipped"}    ← mark as shipped without shipping
+```
+
+### Transaction Reuse
+```
+1. Initiate payment → get transaction_id
+2. Complete purchase
+3. Reuse same transaction_id for second purchase:
+   POST /api/checkout {"transaction_id": "USED_TX", "cart": "new_cart"}
+```
+
+### Limit Count Manipulation
+```
+Daily transfer limit = $1000
+→ Transfer $999, cancel, transfer $999 (limit not updated on cancel)
+→ Parallel transfers (race condition on limit check)
+→ Different payment types not sharing limit counter
+```
+
+### Java Web "No Filter, No Spring Security" Anti-Pattern
+
+Audit-friendly tell: a Spring Boot project that does **NOT** include `spring-boot-starter-security` and has zero `Filter` classes. This means every controller is wide-open for `guest` unless the developer manually checked the session in each method. Reproduce:
+```bash
+# Inside the source tree
+find . -name "*.java" -exec grep -l "Filter" {} \;     # likely empty
+find . -name "*.java" -exec grep -l "@PreAuthorize\|@Secured" {} \;
+```
+If both are empty, expect almost every API to be unauthorized. From the audit demo:
+```java
+public Result score(@RequestParam("userId") Integer userId) {
+    Score score = scoreService.selectScoreByUserId(userId);
+    return Result.success(score);
+}
+```
+No check that `userId` matches the session's logged-in user → horizontal IDOR. Worse: the same endpoint works **without any Cookie**, since nothing forces authentication globally.
+
+### Spring Security `antMatchers` Coverage Gap
+
+The audit videos also showed a partially-secured Spring Security config like:
+```java
+.antMatchers("/system/user/info").authenticated()
+.antMatchers("/system/menu/**").hasRole("admin")
+```
+A common error is an over-narrow rule — e.g. `/system/user/info` is protected but `/system/user/list` is not, or `/system/menu/**` is admin-only but `/system/dept/treeData` is open. Cross-check the controller annotations (`@PreAuthorize("@ss.hasPermi('system:user:list')")`) against the SecurityConfig — every annotated endpoint must also map to a SecurityConfig rule. Mismatches are common after refactors.
+
+---
+
+## 7. SUBSCRIPTION / TIER CONFUSION
+
+```
+Free tier: cannot access feature X
+Paid tier: can access feature X
+
+Attack: 
+- Sign up for paid trial → enable feature X → downgrade to free
+  → Does feature X get disabled on downgrade? 
+  → Can you continue using feature X?
+
+Or:
+- Inspect premium endpoint list from JS bundle
+- Directly call premium endpoints with free account token
+→ Server checks subscription for UI but not API?
+```
+
+### Direct Media URL Leak — VIP Resource Bypass
+
+Real cases from a fitness/learning app: when the client requests course detail, the JSON response embeds the raw media URL:
+```http
+GET /gerudo/v2/liveCourse/625020ce8f002700010554c1/detail HTTP/1.1
+{
+  "previewPullUrl": "http://app-live.../live/app-live_625020ce8f002700010554c2_Preview.flv"
+  ...
+}
+```
+Search **all** detail / preview / playback responses for keywords:
+```
+.flv  .m3u8  .mp4  .mp3  videoUrl  downloadUrl  streamUrl  previewPullUrl
+```
+For each hit, replay the URL anonymously (curl, VLC, flv.js demo at `https://bilibili.github.io/flv.js/demo/`). If the URL plays without a session, you've broken VIP gating. Defense: use signed, short-TTL URLs bound to user/IP/Referer, not raw resource paths.
+
+### Resource ID Replacement — Free → Paid Course
+
+Companion bug: free course detail returns `{"id": "60caa21e853f5c1651b27c1b", ...}`. Replace the ID in the URL with a known paid course ID. If the response structure remains the same and includes the playable URL → IDOR on premium content. Defense: verify the **owner relation** on each detail call, not just "is logged-in".
+
+---
+
+## 8. FILE UPLOAD BUSINESS LOGIC
+
+For the full upload attack workflow beyond pure logic flaws, also load:
+
+- [upload insecure files](../upload-insecure-files/SKILL.md)
+
+```
+Upload size limit: 10MB
+→ Upload 10MB → compress client-side → server decompresses → bomb?
+(Zip bomb: 1KB zip → 1GB file = denial of service)
+
+Upload type restriction:
+→ Upload .csv for "data import" → inject formulas: =SYSTEM("calc")
+  (CSV injection in Excel macro context)
+→ Upload avatar → server converts → attack converter (ImageMagick, FFmpeg CVEs)
+
+Storage path prediction:
+→ /uploads/USER_ID/filename
+→ Can you overwrite other user's file by knowing their ID + filename?
+```
+
+---
+
+## 9. TESTING APPROACH
+
+```
+For each business process:
+1. Map the INTENDED flow (happy path)
+2. Ask: "What if I skip step N?"
+3. Ask: "What if I send negative/zero/MAX values?"
+4. Ask: "What if I repeat this step twice?" (idempotency)
+5. Ask: "What happens if I do A then B instead of B then A?"
+6. Ask: "What if two users do this simultaneously?"
+7. Ask: "Can I modify the 'trusted' status fields?"
+8. Think from financial/resource impact angle → highest bounty
+```
+
+For the formal 5-phase workflow — Business Modeling → State Machine → Attack-Surface Matrix → Checklist-Driven Testing → Human Judgement — load **[METHODOLOGY.md](./METHODOLOGY.md)**. It includes a single-page decision tree (`Q1 ~ Q7`) for "I'm staring at a request and don't know what to try first".
+
+---
+
+## 10. HIGH-IMPACT CHECKLISTS
+
+For the full per-module list (login / register / password recovery / payment / coupon / order / IDOR / privacy / VIP / URL redirect / cookie & token / race / comments) with `why` and `verify` columns — load **[CHECKLIST.md](./CHECKLIST.md)**.
+
+The condensed top-impact items below are the "if you have only 30 minutes, hit these first" set:
+
+### E-commerce / Payment
+```
+□ Negative quantity / decimal quantity (skuQty=0.02, FoodNum=0.01) in cart
+□ Drop required fields (delete prizeIdList) to coerce free tier
+□ amount=999999999 integer overflow → final 0
+□ Apply multiple conflicting coupons via array params
+□ Race condition: double-spend gift card / same coupon
+□ Skip payment step directly to order confirmation  
+□ Server-trusted client status fields (payment_status=paid, success:true)
+□ Refund without return (trigger refund on delivered item via state change)
+□ Multi-device concurrent VIP subscription / 补差价升级
+□ Currency rounding exploitation (¥0.019 charge → ¥0.02 wallet credit)
+```
+
+### Authentication / Account
+```
+□ 2FA bypass by direct URL access after password step
+□ Filter bypass: ../../path traversal truncation, ;path-parameter truncation
+□ Password reset token reuse after email change
+□ Weak random reset token: md5(rand()) on Windows PHP, predictable seed
+□ Email verification bypass (change email after verification)
+□ OAuth account takeover via email match
+□ Register with existing unverified email
+□ Cookie replacement (admin → user / user → another user)
+□ Real-name verification "故意填错" replay-to-reset
+```
+
+### Subscriptions / Limits / Resources
+```
+□ Access premium features after downgrade
+□ Exceed rate/usage limits via parallel requests (Turbo Intruder)
+□ Referral loop for infinite credits
+□ Free trial ≠ time-limited (no enforcement after trial)
+□ Direct API call to premium endpoint without subscription check
+□ Free-course ID swap to paid-course ID (IDOR on resource)
+□ Direct media URL exposure in JSON (.flv / .m3u8 / .mp4 in response)
+□ Server-side RBAC residue (sys_menu duplicate rows)
+□ Java Web no-Filter / Spring Security antMatchers gap
+```
+
+---
+
+## 11. CONSOLIDATED CHECKLIST (2-Hour Full Sweep)
+
+The Section 10 list is the "30-minute money grab". This list is the next layer:
+when you have a couple of hours and want a defensive-grade sweep across all
+nine business surfaces. It's organized by surface, then by attack mechanism
+inside the surface, so you can read a column-down for "what classes of bug
+might exist on this endpoint" and a row-across for "where else does this
+attack apply".
+
+For full `item / why / verify` triplets including reproduction steps and
+tooling per item, load **[CHECKLIST.md](./CHECKLIST.md)**. This section
+keeps only the item line for fast scanning.
+
+### 11.1 Login / Authentication
+```
+□ Username enumeration via response diff (msg / status code / timing)
+□ Username enumeration via SMS-send response (sent vs not-registered)
+□ Brute force without lockout (no rate limit on failed login)
+□ Default / weak credentials (admin/admin, root/123456) on backend & infra
+□ 2FA bypass via direct URL after password step / replay 2FA token
+□ Client-trusted login flag (status=success, is_login=true in response body)
+□ Third-party / SSO callback IDOR (modify uid in callback to take over)
+□ Biometric liveness bypass (replay static photo / pre-recorded video)
+□ Open redirect in login/register (return_url, redirect, callback param)
+□ Hardware-key signature replay / forgery (USB-Key, PKI cert)
+```
+
+### 11.2 Registration
+```
+□ Username / phone / email enumeration via "already exists" response
+□ Password strength only enforced client-side (set 123456 server-side)
+□ Skip multi-step registration (POST final step directly, miss email verify)
+□ Verification code not enforced (empty / random / fixed value passes)
+□ SMS / email code replay (same code used twice or across users)
+□ Re-register same username after logout, inherit old data / privileges
+□ Anti-fraud bypass via N similar virtual accounts (same device, diff email)
+□ Mass-register replay-protection missing (no nonce on submit step)
+```
+
+### 11.3 Password Recovery / Reset
+```
+□ Reset target tampering (uid / email / phone in submit step)
+□ Reset token predictable (timestamp-derived, weak hash, short random)
+□ Cross-user token reuse (A's reset_token, change B's password)
+□ Old-password check missing on logged-in change-password endpoint
+□ Skip code-verify step, hit final reset endpoint directly
+□ Reset link / answer / token leaked in HTML or JS source
+□ Reset token has no expiry / not invalidated after use
+□ Reset code base64-only "obfuscated" in response
+□ Inconsistent identity across multi-step flow (reset_token from step 2
+  reusable in step 4)
+□ Old session not revoked after email/phone re-bind
+```
+
+### 11.4 Session / Token
+```
+□ Session fixation: pre-login session id remains valid after login
+□ Token not bound to user/IP/device (steal cookie → use anywhere)
+□ Forged token: weak algorithm md5(username + timestamp), no server salt
+□ Stale token still accepted after logout / expiry (no blacklist)
+□ Cookie tampering (uid / role / is_admin in cookie trusted server-side)
+□ State-machine replay (replay "claim red packet" → re-claim)
+□ Anti-replay missing on one-time tokens (CSRF token, OTP, nonce)
+□ Sensitive credentials (token, answer, key) hardcoded in front-end JS
+□ Privileged session created from public Session ID without re-auth
+□ Token works cross-environment (different IP, different UA, no validation)
+```
+
+### 11.5 Payment / Order
+```
+□ Amount tampering: amount = 0.01 / 0 / negative / 0.001
+□ Quantity tampering: quantity = -1 / 0.01 / 1.5 / 999999999
+□ Integer overflow: quantity * price wraps to 0 or negative
+□ Floating-point precision exploit (multi-decimal, accumulated rounding)
+□ Currency code swap (CNY → JPY/RUB at same numeric value)
+□ Coupon / discount field forge (coupon_id, discount=, free_shipping=true)
+□ Item ID swap: replace product_id with cheaper SKU at checkout
+□ Signature / sign-field bypass (drop sign param, use stale sign)
+□ Payment-callback forgery (status=paid posted to internal callback)
+□ Replay paid request → multiple shipments / multiple credit
+□ Race / concurrency: oversell, double-spend gift card, double redeem coupon
+□ Refund without losing the merchandise / virtual rights
+□ VIP duration tampering (days=999, months=120, period=-1)
+□ Receiver-account redirect (merchant_id / receiver_account swap on withdraw)
+□ Negative shipping / fee fields decreasing total (shipping_fee = -500)
+□ Concurrent topup-then-refund draining (refund > topup in race window)
+□ Pricing rule transition window (price changes at T, replay at T-ε with old rule)
+□ Currency rounding micro-arbitrage (charge 0.019 → wallet credit 0.02)
+□ Multi-channel inconsistency (online vs cash-on-delivery vs balance pay)
+```
+
+### 11.6 IDOR / Authorization
+```
+□ Horizontal IDOR: uid / order_id / resource_id swap to victim's
+□ Vertical IDOR: role / type / level field set to admin in request
+□ Hidden field tampering (data-user-id in HTML / JS state)
+□ Email / phone re-bind without verifying old binding
+□ UID vs session-token consistency missing (token belongs to A, uid sent as B)
+□ Predictable / sequential resource IDs (gift IDs, share-link IDs)
+□ Resource enumeration on order / coupon / share / trip-detail endpoint
+□ Multi-entry inconsistency: web blocks, mobile API doesn't
+□ State-machine illegal transition (claim reward without paying / shipping
+  before order paid)
+□ Hidden / undocumented admin endpoint accessible without admin auth
+□ Cross-role function call (user calls merchant API, rider API, etc.)
+□ Privilege via concurrent action (request role-elevation race condition)
+```
+
+### 11.7 CAPTCHA / Verification Code
+```
+□ Code returned in plaintext in HTTP response (body / header / JS var)
+□ Receiver tampering: change phone / email param to attacker-controlled
+□ Empty / fixed code accepted (000000, blank, "test")
+□ Drop the code field entirely → request still succeeds
+□ Cross-account reuse (A's valid code accepted on B's flow)
+□ One-time enforcement missing (same code reusable until expiry)
+□ Brute force 4-6 digit code (no attempt limit, no lockout)
+□ SMS / email bombing (no rate limit per IP / per phone / no graphical CAPTCHA)
+□ Front-end-only "send-success" status (server says fail, FE says success)
+□ Code not bound to session (code generated for A, used in B's session)
+```
+
+### 11.8 File Upload
+```
+□ Content-Type bypass (Content-Type: image/jpeg, body is PHP)
+□ Extension trick: double ext (.php.jpg), case mix (.Php), null byte, ;path
+□ Filename path traversal (filename=../../webshell.php)
+□ File-content polyglot (image with embedded PHP / shell)
+□ Office XML repack (unzip docx → inject XML → rezip → upload)
+□ XXE via .xml / .dtd upload endpoint
+□ Backend-only upload (admin login → upload → exec)
+□ Upload race: upload + parallel access before AV scan / cleanup
+□ ZIP bomb (1KB → 1GB on server, decompress DoS)
+□ CSV formula injection (=SYSTEM("calc"), =cmd|'/c calc'!A1)
+□ Storage path predictable / overwritable across users (/uploads/UID/file)
+□ Image converter / parser CVE (ImageMagick, FFmpeg, pillow)
+```
+
+### 11.9 CSRF / SSRF / XXE
+```
+□ XXE file read (<!ENTITY x SYSTEM "file:///etc/passwd">)
+□ XXE blind via OOB (parameter entity → DNSLog / Burp Collaborator)
+□ SSRF via image-import / webhook / preview URL (file://, http://127.0.0.1)
+□ SSRF via FTP / gopher / jar / php-wrapper / dict protocols
+□ XML parser dangerous wrappers enabled (php://expect, expect://)
+□ Out-of-band detection for blind injection (DNSLog confirms server hit)
+□ CSRF on state-changing endpoint (no token, no SameSite, no origin check)
+□ Payment / withdrawal CSRF via auto-submitting hidden form
+□ Login CSRF (force victim to log into attacker account)
+□ JSONP / JSONP-callback exploitation as CSRF read primitive
+```
+
+### How to Use This Section
+
+1. Print or screenshot the relevant 1-2 sub-sections for the target's surface.
+2. For each `□` mark: NOT-APPLICABLE / NOT-VULN / VULN / NEEDS-RECHECK.
+3. Mark the EXACT endpoint + parameter + payload that proved the bug
+   (or proved it absent), so the report is reproducible.
+4. Cross-reference with `METHODOLOGY.md` Q1~Q7 decision tree when an item
+   triggers something unexpected — the tree tells you which neighboring
+   items are likely also vulnerable.
+5. For deep payloads / curl-ready commands / Burp screenshots per item,
+   load `CHECKLIST.md` (full triplets) and `SCENARIOS.md` (real cases).
+