Race Conditions TryHackMe

Overview

Race conditions happen when the outcome of a workflow depends on timing: two (or more) concurrent requests hit shared state and the app fails to enforce correct ordering/atomicity. In web apps, that often means you can double-spend, apply discounts multiple times, bypass limits, or desync account state.

Core idea: Time-of-Check to Time-of-Use (TOCTOU). The app checks something, but the state changes before it uses that result.

1) Classic real-world + web impact examples

Reuse a single gift card / coupon multiple times
Apply the same discount twice (or N times)
Withdraw/transfer more than your balance
Bypass “one action per user” limits (vote/like/redeem)

Signal: anything involving balance, inventory, redemption, or state transitions is a candidate.

2) Why it happens

It’s usually shared state + concurrency + missing locks/transactions.

Parallel execution: server handles multiple requests at once.
DB read-modify-write: two requests read the same value and both write “valid” updates.
Weak isolation: no row locking / no atomic update.
External services: third-party APIs not designed for concurrency can desync your logic.

3) Mental model: state machines

Most race bugs are broken state transitions. If the app has states like created → paid → shipped, a race can let you trigger transitions out of order or twice.

Attack plan: identify the state-changing request, then send it concurrently before the server commits the first transition.

4) Testing workflow (Burp Suite Repeater)

Find the sensitive action endpoint (apply coupon, redeem, transfer, checkout).
Capture a valid request (including auth/session headers).
Send the same request concurrently (or send a pair: check + execute) to trigger TOCTOU.
Compare outcomes: did you get duplicated effects or inconsistent state?

Goal: two requests should not both succeed if the business rule says only one should.

5) What to look for (high-signal targets)

Coupon / gift card redemption
Wallet top-ups / withdrawals / transfers
Inventory / ticket booking / reservations
Rate-limited actions enforced only in app logic (not DB)

6) Remediation (report-ready)

Make state changes atomic (single DB statement where possible).
Use proper locking: row locks / SELECT ... FOR UPDATE where needed.
Enforce idempotency (idempotency keys) for critical actions.
Use correct transaction isolation and consistent reads.
Move business invariants to the data layer (constraints) when possible.

Exam Notes (PT1) — Race Condition checklist

Map the workflow and identify the state-changing request(s).
Try parallel requests: same request twice, or check+execute concurrently.
Watch for duplicated effects (double redemption) and inconsistent balances/states.
Document timing window + impact clearly (money/inventory/state integrity).