race-conditions

Race Conditions Detection

Overview

A race condition is a timing flaw: the application validates a condition at one instant and acts on it at a slightly later instant, and in the interval between the two it is in a temporary, inconsistent sub-state. Because the outcome depends on how concurrent requests interleave rather than on what any one request contains, a rule that holds perfectly for sequential traffic collapses under overlapping requests. These flaws sit in the server-side path between a check and the commit it authorises, and in any place where composite state is written one piece at a time. The attacker is an ordinary user who can send many requests at once with tight timing, so that two of them both pass the check before either performs the update. What they gain mirrors whatever the guarded operation protects: a single-use code redeemed many times, a balance overdrawn, a cap exceeded, a rate limit or challenge defeated, or an object caught half-initialised and used as an identity. This skill finds such flaws by locating every non-atomic check-then-act site, checking each one in parallel, and merging the results into <output_dir>/race-conditions-results.md.

What it is NOT

• Business logic (/websec:business-logic): a logic flaw is exploitable with one ordinary sequence of requests. Test: if you can describe the exploit without any two requests overlapping, it is a logic flaw, not a race. A missing limit is logic; a limit that exists but is momentarily stale is a race.
• Access control (/websec:access-control): those are checks that are absent or wrong and reproduce sequentially. Here the check exists and is correct — it is simply read from state that another request is about to change.
• Authentication (/websec:authentication): a login handler that passes through a window where the session is authenticated but a second factor is not yet enforced is judged here, as a sub-state. A missing or weak factor, or a guessable credential, is not. Predictable token generation is theirs: claim it here only when two overlapping requests collide and are handed the same token, and describe the overlap — a token that is weak on its own, issued one request at a time, is not a race.
• Deadlocks, lost updates in reporting, and performance issues: a concurrency bug is in scope only when the contended value carries money, entitlement, identity, or a security limit.
• Not a finding: a check-then-act pair on state only that caller can reach, where no second party and no second session of the same party can contend for the record; a read-modify-write already wrapped in one transaction whose lock covers the read; an operation whose duplicate execution is idempotent and provably harmless.
• Not proof of safety: apparent serialisation. A framework that locks one request per session makes the race invisible to a naive test while leaving it fully exploitable from two sessions. Record it as a mitigating factor, never as the control.