Listen to this Post
Introduction
Race conditions have long been misunderstood as simply flooding an endpoint with parallel requests to overwhelm a limit. The reality is far more nuanced. As PortSwigger’s research demonstrates, the true potential of web race conditions extends well beyond limit-overrun attacks into the realm of application state manipulation and time-sensitive cryptographic weaknesses. Understanding the difference between a true race condition and a time-sensitive vulnerability—and knowing how to exploit both—separates skilled bug bounty hunters from those who merely run automated tools.
Learning Objectives
- Master the distinction between classic limit-overrun race conditions and time-sensitive cryptographic vulnerabilities
- Learn to identify race windows in application state transitions using Burp Suite’s Repeater and Turbo Intruder
- Understand how timestamp-based token generation creates predictable password reset tokens and how to exploit this weakness
- Develop a systematic methodology for detecting and proving race condition vulnerabilities in production environments
You Should Know
- Understanding the Race Window: The Critical Timing Gap
A race condition occurs when a web application processes concurrent requests without adequate safeguards, leading to multiple threads interacting with the same data simultaneously. The period during which a collision is possible is called the “race window”—often just milliseconds or even microseconds.
The classic example involves a one-time discount code. The application performs three steps: checking if the code has been used, applying the discount, and updating the database to mark the code as used. Between the check and the update exists a temporary sub-state—a brief moment when the application has verified eligibility but hasn’t yet recorded the usage. If two requests arrive during this window, both can apply the discount.
Step-by-step guide to identifying race windows:
- Identify single-use or rate-limited endpoints—look for discount applications, gift card redemptions, CAPTCHA validations, or login attempts
- Benchmark normal behavior—send a single request and observe the response time and state changes
- Create a request group in Burp Repeater—duplicate the request 10-20 times and add them to a new tab group
- Send requests in parallel—use the “Send group in parallel” option to fire all requests simultaneously
- Analyze responses—look for anomalies: multiple success responses, different error messages, or unexpected state changes
Turbo Intruder script for race condition testing:
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=10,
engine=Engine.BURP2)
Queue the target request multiple times
for i in range(20):
engine.queue(target.req, gate='race1')
Open the gate to release all requests simultaneously
engine.openGate('race1')
2. The Single-Packet Attack: Eliminating Network Jitter
Network jitter—unpredictable delays in packet transmission—has historically made remote race condition exploitation unreliable. PortSwigger’s single-packet attack solves this by completing multiple HTTP/2 requests within a single TCP packet.
The technique works by:
- Issuing all requests over a single HTTP/2 connection
- Withholding a tiny fragment from each request so the server doesn’t start processing
- Waiting briefly for packets to arrive on the target server
- Issuing the final fragment of each request simultaneously
Your operating system groups these into a single TCP packet, meaning all requests get processed at the same time regardless of network latency. This approach scales to 20-30 requests and is available in Burp Repeater’s tab group functionality.
To use the single-packet attack in Burp Repeater:
1. Send your target request to Repeater
- Right-click the tab and select “Duplicate tab” 10-20 times
- Right-click any tab and select “Add to group” → “Create new group”
- In the group settings, ensure “Send in parallel” is selected
- Click “Send group” to execute the single-packet attack
3. Time-Sensitive Vulnerabilities: When Cryptography Fails
Not every timing-related vulnerability is a race condition. The “Exploiting time-sensitive vulnerabilities” lab on PortSwigger demonstrates a password reset mechanism that generates tokens using timestamps rather than cryptographically secure random sources.
The vulnerability arises when:
- Password reset tokens are generated using a timestamp as an input to a hash function
- The username is not included in the hash
- Multiple reset requests submitted at the same timestamp produce identical tokens
Step-by-step exploitation of time-sensitive password reset:
- Study the reset mechanism—submit a password reset for your own account and observe the token format
- Send multiple reset requests—use Burp Repeater to send two reset requests in parallel
- Bypass session locking—PHP backends often process only one request per session at a time. Remove the session cookie from one request to get a new session, then use that session for your second request
- Observe token collision—when response times match, both emails contain identical reset tokens
- Change the username—modify one request’s username parameter to the target user (e.g.,
carlos) and resend in parallel
Critical insight: The token’s consistency in length suggests either random generation or a hash of predictable data. The fact that tokens differ each time indicates internal state—often a timestamp. When two requests hit the same millisecond, they produce the same hash.
Linux command to generate timestamp-based tokens (for educational understanding):
Generate a token using timestamp (insecure - demonstration only)
date +%s%3N | sha256sum | cut -c1-32
Compare tokens generated at the same time
for i in {1..5}; do date +%s%3N | sha256sum | cut -c1-32; done
4. Beyond Limit Overruns: Hidden Multi-Step Sequences
Race conditions manifest in more complex forms than simple limit overruns. Partial construction race conditions occur when an application creates a resource in multiple steps, and an attacker can access the resource before it’s fully initialized.
In the partial construction lab, the application:
- Generates a registration token when a user signs up
2. Stores the token in the database
3. Sends a confirmation email with the token
The race window exists between token generation and database storage. During this window, a null or empty token value may be considered valid.
Exploitation methodology:
1. Register a user and intercept the request
- Craft a confirmation request with an empty token parameter or `token[]=` (empty array)
- Send registration and confirmation requests in parallel using the single-packet attack
- If successful, the confirmation request processes before the token is stored, accepting the empty value as valid
Windows command to monitor race conditions (for testing environments):
Use PowerShell to send parallel web requests
$uris = @("https://target.com/endpoint?param=value") 20
$uris | ForEach-Object -Parallel {
Invoke-WebRequest -Uri $_ -Method POST -Body "data=payload"
} -ThrottleLimit 20
5. Bypassing Rate Limits Through Race Conditions
Rate limiting is a common defense against brute-force attacks, but race conditions can bypass it entirely. When the application stores failed login attempts per username and increments a counter, a race window exists between submitting the login attempt and updating the counter.
Practical exploitation:
- Identify the rate limit—observe that after 3 failed attempts, the account locks
- Create 20 duplicate login requests in Burp Repeater with the target username and different passwords from a wordlist
- Send all requests in parallel using the single-packet attack
- Analyze responses—more than 3 requests will return “Invalid username or password” rather than lockout messages, confirming the race condition
Wordlist for testing (common passwords):
123456 password 12345678 qwerty 123456789 12345 1234 111111 1234567 dragon 1234567890 michael x654321 superman 1qaz2wsx
6. Prevention and Mitigation Strategies
Understanding how to prevent race conditions is as important as exploiting them. PortSwigger recommends:
Database-level locking: Use `SELECT … FOR UPDATE` or row-level locks to ensure atomic operations. This prevents two threads from reading the same data simultaneously.
Session-based locking: Process only one request per session at a time. While this impacts performance, it effectively prevents session-based race conditions.
Idempotency keys: Require clients to provide a unique key for each operation. The server tracks used keys and rejects duplicates.
Cryptographically secure random tokens: Always use `random_bytes()` or `openssl_random_pseudo_bytes()` for token generation—never timestamps or predictable values.
Atomic operations: Use database transactions with appropriate isolation levels to ensure operations complete atomically.
Code review checklist for developers:
// VULNERABLE: Check then act
if (!used($code)) {
applyDiscount($code);
markUsed($code);
}
// SECURE: Atomic operation
BEGIN TRANSACTION;
IF NOT used($code) THEN
applyDiscount($code);
markUsed($code);
END IF;
COMMIT;
What Undercode Say
- Race conditions are about state machines, not request volume. The key insight is understanding how applications transition between states and identifying the temporary sub-states where collisions occur. Sending 100 requests blindly is less effective than sending 2 perfectly timed requests.
-
Cryptographic assumptions are dangerous. Developers often assume that any hash equals security. The time-sensitive password reset lab proves otherwise—when timestamps are used as hash inputs, tokens become predictable. Always verify the randomness source.
The most valuable lesson from the PortSwigger labs is that web security testing requires thinking like the developer. Understanding application logic, state transitions, and the underlying architecture (PHP session handling, database isolation levels, network protocols) is far more important than memorizing payloads. The single-packet attack demonstrates how network-level understanding—TCP packet construction, HTTP/2 multiplexing—can be leveraged to exploit vulnerabilities that were previously considered impractical. As bug bounty programs mature, the ability to identify these nuanced vulnerabilities becomes increasingly valuable.
Prediction
- +1 The single-packet attack will become a standard technique in every penetration tester’s toolkit, leading to a surge in race condition discoveries across major platforms
-
+1 AI-assisted code review tools will increasingly flag time-sensitive cryptographic patterns, reducing the prevalence of timestamp-based token generation
-
-1 Legacy PHP applications with session-based locking will remain vulnerable to time-sensitive attacks, as migrating to modern concurrency patterns is often prohibitively expensive
-
-1 The complexity of detecting race conditions will increase as applications adopt microservices and distributed architectures, creating new attack surfaces in inter-service communication
-
+1 Bug bounty programs will expand their scope to include race condition testing, recognizing these vulnerabilities as critical business logic flaws rather than edge cases
-
-1 Organizations that fail to implement atomic operations and proper locking mechanisms will continue to suffer from gift card fraud, discount abuse, and account takeover attacks
-
+1 The open-source community will develop more sophisticated tooling for race condition detection, making the methodology accessible to a broader range of security practitioners
▶️ Related Video (82% Match):
https://www.youtube.com/watch?v=0qNNzO14ufE
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Osama Anwar – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
