Lab 07: Race Conditions (TOCTOU)

Objective

Exploit TOCTOU (Time-of-Check to Time-of-Use) race conditions in a live banking API:

  1. Coupon double-redemption — fire 8 concurrent requests to redeem a single-use £50 coupon, collecting £400 instead of £50

  2. Double-spend transfer — send simultaneous transfers that both pass the balance check before either deducts

  3. Measure the race window — use timing analysis to understand why the vulnerability exists

  4. Implement thread-safe fixes — demonstrate atomic database transactions vs vulnerable read-then-write


Background

Race conditions in web applications exploit the gap between a check (is balance sufficient?) and an action (deduct balance). If multiple requests pass the check simultaneously, all can proceed to the action phase — even when only one should.

Real-world examples:

  • 2022 Solana DeFi protocol — concurrent transaction processing allowed double-spend; $100M+ at risk before emergency patch. TOCTOU at the smart contract level.

  • 2019 GitLab — concurrent file upload requests could bypass file size limits; race window between size check and write to disk.

  • 2021 HackerOne reports (multiple) — coupon/promo code race conditions found in major e-commerce platforms (redacted). Standard TOCTOU in redemption APIs.

  • Banking apps (recurring) — "phantom withdrawal" attacks use concurrent ATM requests faster than the ledger updates. The infamous "unlimited money glitch" on various fintech apps.

OWASP: A04:2021 Insecure Design


Architecture

Time

40 minutes


Lab Instructions

Step 1: Setup


Step 2: Launch Kali and Understand the Race Window


Step 3: Race Condition — Coupon Double-Redemption

📸 Verified Output:


Step 4: Double-Spend — Concurrent Transfers


Step 5: Measure the Race Window


Step 6: Implement the Fix


Step 7–8: Cleanup


Remediation

Further Reading

Last updated