NoorQureshi Race conditions (TOCTOU / limit-overrun)
When it applies
An action is meant to happen once (or N times) and the server checks a condition, then acts, on shared state — without atomicity. Concurrent requests slip between check and update.
Why it works
Between "check if allowed" and "record that it happened" there's a window. Fire many requests in that window and several pass the check before any updates the state — so a one-time coupon redeems 10×, a balance is spent twice, a limit is overrun.
Method
- Pick a limited action with observable state (balance, redeemed flag, count).
- Send a burst in parallel aligned to hit the window together: Burp Turbo Intruder (single-packet attack for HTTP/2, or last-byte sync for HTTP/1) — the point is simultaneity, not volume.
- Measure the overrun: did the action succeed more times than allowed (2 redemptions, double credit)?
- Variants: multi-endpoint races (state set by A, consumed by B), and MFA/OTP brute windows.
Gotchas
- Sequential fast requests aren't a race — you need true concurrency (single-packet / synced send).
- Effect can be small (2× not ∞) but still valid; quantify the actual overrun.
- Idempotency keys / DB locks defeat it — a single success may just be correct behaviour.
Verify success
The limited action occurs more times than the rules allow (e.g. one coupon applied twice, balance double-spent), reproduced with the concurrent PoC.
References
PortSwigger race-condition labs; James Kettle "Smashing the state machine"; Turbo Intruder.