Offensive Race Condition

SKILL: Race Conditions

Metadata

• Skill Name: race-condition
• Folder: offensive-race-condition
• Source: https://github.com/SnailSploit/offensive-checklist/blob/main/race-condition.md

Description

Race condition (TOCTOU) testing checklist: identifying timing windows, Burp Suite Turbo Intruder, Last-Byte sync technique, rate limit bypass, double-spend attacks, and concurrent request exploitation. Use for web app race condition testing or bug bounty time-of-check-to-time-of-use bugs.

Trigger Phrases

Use this skill when the conversation involves any of: race condition, TOCTOU, timing attack, Turbo Intruder, last-byte sync, rate limit bypass, double spend, concurrent request, race window, time of check, time of use

Instructions for Claude

When this skill is active:

1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. Suggest next steps based on findings

---

Full Methodology

Race Conditions

Shortcut

• Spot the features prone to race conditions in the target application and copy the corresponding requests.
• Send multiple of these critical requests to the server simultaneously. You should craft requests that should be allowed once but not allowed multiple times.
• Check the results to see if your attack has succeeded. And try to execute the attack multiple times to maximize the chance of success.
• Consider the impact of the race condition you just found.

Mechanisms

Race conditions occur when the behavior of a system depends on the relative timing or sequence of events that can happen in different orders. In web application security, race conditions happen when multiple concurrent processes or threads access and manipulate the same resource simultaneously without proper synchronization.

sequenceDiagram
    participant Thread1 as Thread 1
    participant Resource
    participant Thread2 as Thread 2

    Thread1->>Resource: Read value (100)
    Thread2->>Resource: Read value (100)
    Thread1->>Thread1: Calculate new value (100-10=90)
    Thread2->>Thread2: Calculate new value (100-10=90)
    Thread1->>Resource: Write new value (90)
    Thread2->>Resource: Write new value (90)
    Note over Resource: Expected final value: 80Actual final value: 90

A race condition becomes a security vulnerability when it affects security controls or business logic. The critical types include:

• Time-of-Check to Time-of-Use (TOCTOU): When a check is performed, but circumstances change before the result of the check is used
• Read-Modify-Write: When multiple processes read, modify, and write back a shared resource without coordination
• Thread Safety Issues: When multithreaded applications improperly handle shared resources
• Resource Allocation Races: Competition for limited resources like database connections or memory

graph TD
    subgraph "Common Race Condition Types"
    A[Race Conditions] --> B[TOCTOU]
    A --> C[Read-Modify-Write]
    A --> D[Thread Safety Issues]
    A --> E[Resource Allocation]

    B --> B1["Check balance, then debit"]
    C --> C1["Update counter or balance"]
    D --> D1["Shared cache or session data"]
    E --> E1["Limited coupon or inventory"]
    end

Common vulnerable scenarios include:

• Account Balance Manipulation: Making multiple withdrawals/transfers simultaneously
• Coupon/Promotion Code Reuse: Using a single-use code multiple times
• File Upload Processing: Uploading and accessing temporary files before validation completes
• Registration Processes: Creating multiple accounts with the same unique identifier
• Token Verification: Using authentication tokens multiple times before they're invalidated

Hunt

Identifying Race Condition Vulnerabilities

Target Functionality Selection

Focus on features handling state changes, limited resources, or critical operations:

• Financial Transactions: Fund transfers, withdrawals, purchases
• Inventory Systems: Stock allocation, reservation systems
• Coupon/Points Systems: Redeeming coupons, points, or rewards
• Voting/Rating Systems: Likes, upvotes, downvotes, polls
• Membership/Subscription Actions: Inviting users, joining/leaving groups, following/unfollowing users
• Registration Systems: Account creation with unique attributes
• Resource Management: Uploading, processing, or accessing resources
• Rate-Limited Actions: Password resets, login attempts, API endpoints with usage limits

Testing Prerequisites

1. Tools for sending parallel requests:

• Burp Suite Turbo Intruder or Repeater (multi-threaded)
• Custom scripts with threading capabilities
• Race condition testing frameworks (e.g., Racepwn)

1. Request capturing and analysis capabilities:

• HTTP proxy for intercepting and modifying traffic
• Response analysis tools for detecting race-related anomalies

1. Network Proximity: Consider the physical or network location of your testing infrastructure relative to the target server. Minimizing latency (e.g., using a VPS in the same region/provider as the target) can significantly increase the chances of winning a race condition.

Testing Methodology

flowchart TD
    A[Race Condition Testing] --> B[Baseline Analysis]
    A --> C[Race Condition Detection]
    A --> D[Timing Manipulation]
    A --> E[Proof of Concept]

    B --> B1[Identify state-changing operations]
    B --> B2[Document normal transaction flow]

    C --> C1[Send identical requests simultaneously]
    C --> C2[Observe state changes]

    D --> D1[Identify critical timing windows]
    D --> D2[Vary delays between requests]

    E --> E1[Create reproducible exploit]
    E --> E2[Document impact scenarios]

1. Baseline Behavior Analysis:

• Identify state-changing operations
• Understand normal request/response patterns
• Document application's standard transaction flow

1. Race Condition Detection:

• Send identical requests simultaneously (10-100 threads)
• Observe effects on application state
• Look for anomalies in responses or state changes

1. Timing Manipulation:

• Identify critical timing windows
• Target synchronization points
• Test with varying delays between requests

Advanced Testing Techniques

API-Based Race Condition Testing

1. Identify stateful API endpoints
2. Create automated scripts for parallel API requests:

import requests
import threading

def make_request():
    requests.post('https://target.com/api/redeem',
                  json={'coupon_code': 'ONCE123'},
                  headers={'Authorization': 'Bearer token'})

threads = []
for _ in range(20):
    t = threading.Thread(target=make_request)
    threads.append(t)
    t.start()

for t in threads:
    t.join()

Transaction-Based Race Condition Testing

1. Identify multi-step transactions
2. Find the critical state change requests
3. Execute the final step in parallel before state updates propagate:

`` Step 1: Start purchase (single request) Step 2: Apply coupon (single request) Step 3: Send 20 simultaneous "confirm order" requests ``

Thread Synchronization Testing

Create coordinated attacks that target specific timing windows:

import requests
import threading
import time

start_gate = threading.Event()

def synchronized_request():
    start_gate.wait()  # All threads wait here until flag is set
    requests.post('https://target.com/api/withdraw',
                  json={'amount': '100'},
                  headers={'Authorization': 'Bearer token'})

threads = []
for _ in range(50):
    t = threading.Thread(target=synchronized_request)
    t.daemon = True
    threads.append(t)
    t.start()

# Release all threads simultaneously
time.sleep(2)  # Ensure all threads are waiting
start_gate.set()

Network-Level Timing Manipulation

Beyond application-level threading, manipulating network-level timing can be effective:

• HTTP/2 / HTTP/3 Single-Packet & Last-Byte-Sync Techniques: Classic HTTP/1.1 pipelining is disabled on most servers. Modern testers rely on HTTP/2 multiplexing or HTTP/3 streams to achieve micro-second concurrency. Burp Repeater (2023.9+) and Turbo Intruder expose this as Send group in parallel (single-packet attack).
• Last-Byte-Sync / Request Splitting: Open multiple connections, send almost-complete requests, then flush the final bytes simultaneously. In Burp, send each tab using the single packet attack gate; or in Turbo Intruder:

def queueRequests(target, wordlists):
    engine = RequestEngine(
        endpoint=target.endpoint,
        concurrentConnections=1,
        engine=Engine.BURP2)

    for _ in range(20):
        engine.queue(target.req, gate='race')

    engine.openGate('race')

Rate-Limiter and CAPTCHA Races

• Send concurrent login or OTP requests across multiple sessions/IPs to probe shared counters.
• Look for global vs per-user vs per-IP buckets; test burst vs sustained patterns.

Vulnerabilities

Common Race Condition Vulnerability Patterns

graph LR
    subgraph "Race Condition Vulnerability Impacts"
    A[Race Conditions] --> B[Financial Systems]
    A --> C[Account & Authentication]
    A --> D[Resource Management]
    A --> E[Application-Specific]
    A --> F[Rate Limiting & Anti-Automation]

    B --> B1[Double Withdrawal]
    B --> B2[Transaction Rollback Abuse]

    C --> C1[Multiple Account Creation]
    C --> C2[Token Reuse]
    C --> C3[MFA Bypass]

    D --> D1[Upload-Download Race]
    D --> D2[Resource Over-allocation]

    E --> E1[Shopping Cart Race]
    E --> E2[Auction Sniping]
    F --> F1[OTP/Reset Code Reuse]
    F --> F2[CAPTCHA Reuse]
    end

Financial Systems Vulnerabilities

• Double Withdrawal: Processing the same withdrawal request twice
• Transaction Rollback Abuse: Initiating a transaction rollback while completing the transaction
• Balance Check Bypass: Racing between balance verification and transaction processing

Account and Authentication Vulnerabilities

• Multiple Account Creation: Creating accounts with the same unique identifier
• Token Reuse: Using one-time tokens multiple times
• Session Fixation Race: Racing between session creation and authentication
• MFA Bypass: Racing between MFA checks and authenticated resource access

Resource Management Vulnerabilities

• Upload-Download Race: Accessing uploaded files before security checks complete
• Resource Allocation Race: Over-allocating limited resources
• Temporary File Races: Operating on temporary files during processing

Specific Application Patterns

• Shopping Cart Race Conditions: Adding items at specific discount windows
• Auction Sniping Race: Timing bids to bypass minimum increments
• Reservation System Races: Double-booking limited inventory

Time-Sensitive Vulnerabilities

1. Send parallel password reset requests for the same account
2. Check if reset tokens are identical
3. Test by changing victim's username in one request
4. Analyze response times for potential race conditions

Session Handling Bypass

Some application frameworks (like PHP with default session handling) lock session files when session_start() is called, preventing concurrent requests from the same session from executing simultaneously. If the application allows a user to have multiple active sessions, this can be bypassed:

1. Authenticate multiple times to obtain several valid session identifiers (e.g., PHPSESSID).
2. Assign a unique session ID to each concurrent request in your race condition attack. This makes the server treat each request as originating from a different session, circumventing the session lock.

Database Isolation Level Testing

Different database isolation levels handle concurrency differently. Test each level to identify race vulnerabilities:

PostgreSQL Isolation Levels:

-- READ UNCOMMITTED (treats as READ COMMITTED in PostgreSQL)
BEGIN TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

-- READ COMMITTED (default) - prone to races
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT balance FROM accounts WHERE id = 123;
-- Race window here
UPDATE accounts SET balance = balance - 100 WHERE id = 123;
COMMIT;

-- REPEATABLE READ - prevents some races
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- SERIALIZABLE - strongest protection
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Testing Strategy:

1. Identify critical transactions in the application
2. Send concurrent requests during the transaction window
3. Check if inconsistent state occurs
4. Test with explicit table locking:

``sql SELECT * FROM table FOR UPDATE; -- Row-level lock LOCK TABLE table IN EXCLUSIVE MODE; -- Table-level lock ``

MySQL/MariaDB:

-- Test for missing row locks
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 123;
-- Send parallel transactions here
UPDATE accounts SET balance = balance - 100 WHERE id = 123;
COMMIT;

-- Test with explicit locking
SELECT * FROM accounts WHERE id = 123 FOR UPDATE;

Testing for Advisory Locks:

-- PostgreSQL advisory locks
SELECT pg_try_advisory_lock(12345);

-- Test if application uses them
-- Send parallel requests and monitor pg_locks table
SELECT * FROM pg_locks WHERE locktype = 'advisory';

WebSocket Race Conditions

WebSocket connections maintain persistent state and can be vulnerable to race conditions:

Message Processing Races:

// Send concurrent WebSocket messages
const ws = new WebSocket("wss://target.com/socket");

ws.onopen = () => {
  // Send multiple messages rapidly
  for (let i = 0; i >Application: Identify state-changing operations
    Tester->>Application: Create test accounts
    Tester->>Tester: Prepare concurrent request tools

    Note over Tester: Discovery Phase
    Tester->>Application: Send 50+ parallel requests
    Application->>Database: Multiple concurrent operations
    Note over Database: Race condition occurs
    Database->>Application: Inconsistent state
    Application->>Tester: Observe anomalous behavior

    Note over Tester: Exploitation Phase
    Tester->>Tester: Fine-tune timing parameters
    Tester->>Application: Execute optimized attack
    Tester->>Tester: Document impact

1. Preparation Phase:

• Map application functionality with state changes
• Create multiple test accounts
• Prepare parallel request tools and monitoring

1. Discovery Phase:

• Test for TOCTOU issues in all critical functions
• Test multi-step transactions with simultaneous final steps
• Look for resource contention vulnerabilities
• Test file operations for race conditions

1. Exploitation Phase:

• Fine-tune timing and concurrency parameters
• Create proof-of-concept exploits for confirmed issues
• Measure impact with controlled exploitation
• Document findings with clear reproduction steps

1. Verification Phase:

• Test different concurrency levels (10, 50, 100 requests)
• Vary timing patterns (synchronized vs staggered)
• Test across different network conditions

Real-World Testing Examples

E-commerce Application Testing

1. Add limited stock item to cart
2. Send 20 simultaneous checkout requests
3. Verify if multiple purchases succeed despite limited inventory

Banking Application Testing

1. Identify fund transfer functionality
2. Create 50 simultaneous transfer requests for the same amount
3. Verify account balance after transfers complete
4. Check for transaction logs inconsistencies

API Testing for Race Conditions

1. Identify stateful API endpoints
2. Create requests that modify shared resources
3. Execute requests simultaneously from multiple clients
4. Verify resource state consistency

Advanced Race Condition Scenarios

Multi-E

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: SnailSploit
• Source: SnailSploit/Claude-Red
• License: MIT

Install and usage instructions live in the source repository linked above.