Module 7 · Business Logic Flaws 🔒

Business logic flaws are where the commercially-important findings live. Unlike SQL injection or XSS, they can’t be detected by scanners or generic rules — they require understanding of how the application is supposed to work and identifying where that logic breaks under hostile input.

The findings in this category tend to produce the largest direct financial impact. A race condition in a refund endpoint that lets an attacker withdraw the same credit twice. A workflow bypass that lets a user skip KYC. A price-manipulation vulnerability that accepts a negative quantity and pays the attacker. These bugs have cost real Indian fintechs real crores. Testing for them is the difference between a credible pentest and a scanner report.

The mental model

Business logic vulnerabilities are mismatches between the application’s intended flow and what its code actually enforces. The attacker asks: “What does this feature assume the user will do? What happens if they don’t?”

Examples:

• The password-reset flow assumes the user will click the link once. What if they click it simultaneously from two devices?
• The checkout assumes positive quantities. What if quantity is negative?
• The coupon check assumes one coupon per order. What if two are applied in parallel requests?
• The KYC workflow assumes step 1 completes before step 2. What if the attacker calls step 3 directly?

Race conditions — the treasury drainer

Classic race condition setup: the application reads state, validates it, then writes state. Between read and write, a second request can interfere — if the second request reads the same state before the first writes, both requests proceed with stale data.

The withdrawal example

// Vulnerable withdrawal handler
function withdraw(userId, amount) {
    const balance = db.getBalance(userId);   // READ
    if (balance >= amount) {                  // CHECK
        db.setBalance(userId, balance - amount);  // WRITE
        sendMoney(userId, amount);
    }
}

Normal flow: user balance is 1000, they withdraw 800, balance becomes 200.

Race exploit: attacker sends two simultaneous withdrawal requests for 800 each. Both read balance = 1000 before either writes. Both pass the check. Both write balance = 200. Both send 800. Net: attacker withdrew 1600 from a 1000 balance.

Where races hide

• Balance and wallet operations
• Coupon and promo code redemption
• Referral bonus crediting
• Voucher redemption
• Gift card balance consumption
• Limited-quantity offers (concert tickets, flash sales)
• Cashback calculation
• Subscription upgrades/downgrades
• Withdrawal requests
• Refund processing

Exploitation with Turbo Intruder

Burp Turbo Intruder is the standard tool. It sends multiple HTTP requests in the “last byte synchronization” pattern — all requests are pre-sent but held; then the final byte of each is released simultaneously so all arrive at the server in the same ~millisecond.

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=30, requestsPerConnection=1)
    for i in range(30):
        engine.queue(target.req, gate='race1')
    engine.openGate('race1')

def handleResponse(req, interesting):
    table.add(req)

-- Pessimistic: lock the row during the transaction
BEGIN;
SELECT balance FROM accounts WHERE user_id = ? FOR UPDATE;
-- Check and update
UPDATE accounts SET balance = balance - ? WHERE user_id = ? AND balance >= ?;
COMMIT;

-- Or atomic update with conditional WHERE:
UPDATE accounts SET balance = balance - ? WHERE user_id = ? AND balance >= ?;
-- Check rows-affected; if 0, insufficient balance