offensive-business-logic

# Business Logic — Offensive Testing Methodology Business logic flaws are the highest-paying class of vulnerability for bug bounty and the hardest for scanners to detect. They live in the gap between what the developer specified and what an attacker can convince the system to accept. ## Quick Workflow 1. Map every multi-step flow as a state machine (states + allowed transitions + side effects) 2. For each transition, ask: who can call it, in what state, with what inputs, how many times 3. Probe each axis (state, identity, input, frequency) for assumptions 4. Combine flaws — single-axis flaws are usually low severity; chains are critical 5. Quantify financial impact per finding (loss-per-attack × scale) --- ## Reconnaissance — Mapping the Logic ### Build the State Machine For each user flow, draw: - **States**: cart, pending payment, paid, shipped, refunded, cancelled - **Transitions**: which API/UI action, which role, which preconditions - **Side effects**: balance change, inventory change, email, webhook Look for transitions that: - Skip intermediate states (`cart` → `shipped` without `paid`) - Are reversible when they shouldn't be (`shipped` → `cart`) - Trigger side effects more than once - Allow cross-role invocation ### Hidden / Internal Endpoints ```bash # Compare authenticated and unauthenticated JS bundles for buried admin routes diff <(curl https://app/main.js) <(curl -H "Cookie: ..." https://app/main.js) # Look for flag/feature toggles that change UI but n...