Race.Condition.Exploiter.md

Race Condition Exploiter

Overview

Build a fullstack application using FastAPI and React that demonstrates, detects, and exploits TOCTOU (Time of Check to Time of Use) race conditions in web applications. You will create an intentionally vulnerable e-commerce platform with double-spend vulnerabilities, coupon reuse bugs, and concurrent session abuse, then build an exploitation harness that sends parallel requests to trigger the race windows. This project teaches one of the most underexplored vulnerability classes in web security — race conditions are present in nearly every application that handles concurrent state mutations but are rarely tested because they require specialized tooling.

Step-by-Step Instructions

1. Set up the fullstack project with a vulnerable e-commerce backend Initialize a FastAPI backend with PostgreSQL and a React frontend. Build a simple e-commerce platform with user accounts, wallet balances, a product catalog, discount coupons, and an order system. Deliberately implement the purchase flow with a classic TOCTOU vulnerability: check the wallet balance in one query, then deduct it in a separate query without any locking or transaction isolation. Use SQLAlchemy with the default isolation level. Build a React storefront where users can browse products, apply coupons, and make purchases.

2. Implement five distinct race condition vulnerabilities Create five vulnerable endpoints: a double-spend on wallet transfers (check balance then deduct in separate operations), single-use coupon reuse (check if coupon is used then mark as used in separate steps), inventory oversell (check stock count then decrement without locking), concurrent account creation with the same email (check uniqueness then insert), and simultaneous password reset token consumption (check token validity then invalidate). Each vulnerability should be reachable through the normal React UI flow, making them realistic.

3. Build the race condition exploitation harness Create a Python-based exploitation tool that sends precisely timed concurrent HTTP requests to trigger race windows. Implement multiple concurrency strategies: asyncio with aiohttp for async parallelism, threading with requests for thread-based parallelism, and raw socket-level request pipelining for the tightest timing. Add a --threads flag to control concurrency level and a --delay flag to introduce microsecond-level offsets between requests. Implement HTTP/2 connection reuse to eliminate connection setup variance. The harness should report success/failure for each attempt and calculate the exploitation success rate over multiple runs.

4. Create a real-time visualization dashboard Build a React dashboard that visualizes race conditions as they happen. Use WebSocket connections from FastAPI to stream events. Show a timeline where each concurrent request is a horizontal bar, with the check operation and use operation marked as distinct phases. Color-code successful exploits (where two requests both passed the check) versus failed attempts. Display the database state in real-time: wallet balances, coupon usage counts, and inventory levels. This makes the race window visually tangible, which is critical for understanding the vulnerability class.

5. Implement detection mechanisms Build three race condition detection approaches: a middleware-based detector that logs all concurrent requests to the same endpoint with the same resource identifier and flags groups that arrive within a configurable time window, a database trigger approach that detects when a balance goes negative or a coupon usage count exceeds one, and a request fingerprinting system that identifies suspiciously identical requests arriving in bursts. Each detector should feed events into the WebSocket dashboard with explanations of what was detected.

6. Build the fix implementation with toggleable patches For each vulnerability, implement the proper fix using database-level controls: SELECT ... FOR UPDATE row-level locking, serializable transaction isolation, unique constraints with proper error handling, atomic compare-and-swap operations using UPDATE ... WHERE balance >= amount, and optimistic concurrency control with version columns. Make each fix toggleable via a feature flag API endpoint so users can switch between vulnerable and patched modes from the React UI and observe how the exploitation harness results change.

7. Add a benchmarking and analysis mode Create a benchmarking system that runs the exploitation harness against each vulnerability with and without fixes applied, across different concurrency levels (2, 5, 10, 25, 50 concurrent requests), and measures: exploitation success rate, average response time, database deadlock frequency, and throughput impact of the locking mechanisms. Generate comparative charts showing the tradeoff between security and performance. This teaches that fixing race conditions always has a performance cost, and the right fix depends on the acceptable tradeoff.

8. Write comprehensive labs and package with Docker Compose Create seven guided lab exercises, one for each vulnerability plus two focused on detection and fixing. Each lab includes the learning objective, setup steps, exploitation instructions, expected output, fix implementation, and verification. Package everything in Docker Compose with FastAPI, PostgreSQL, Redis (for distributed locking examples), and the React frontend. Include a reset endpoint that restores the database to its initial state so labs can be repeated. Write a reference guide explaining race condition theory, the happens-before relationship, and why application-level locking is insufficient.

Key Concepts to Learn

• TOCTOU (Time of Check to Time of Use) vulnerability mechanics
• Database transaction isolation levels and their security implications
• Row-level locking with SELECT FOR UPDATE and advisory locks
• Optimistic vs pessimistic concurrency control strategies
• HTTP/2 connection multiplexing for precise timing attacks
• Race condition detection through request pattern analysis
• The performance-security tradeoff in concurrency control
• Distributed locking patterns for microservice architectures

Deliverables

• FastAPI e-commerce backend with five race condition vulnerabilities
• React frontend with storefront and real-time visualization dashboard
• Python exploitation harness with multiple concurrency strategies
• Three detection mechanisms with WebSocket-fed dashboard integration
• Toggleable fix system with five database-level remediation patterns
• Benchmarking system comparing exploitation rates across configurations
• Seven guided lab exercises with Docker Compose packaging