Task 2 : Race Condition

A race condition happens when two or more actions occur at the same time, and the system’s outcome depends on the order in which they finish. In web applications, this often happens when multiple users or automated requests simultaneously access or modify shared resources, such as inventory or account balances. If proper synchronisation isn’t in place, this can lead to unexpected results, such as duplicate transactions, oversold items, or unauthorised data changes.

Types of Race Conditions

Generally, race condition attacks can be divided into three categories:

• Time-of-Check to Time-of-Use (TOCTOU): A TOCTOU race condition happens when a program checks something first and uses it later, but the data changes in between. This means what was true at the time of the check might no longer be true when the action happens. It’s like checking if a toy is in stock, and by the time you click "Buy" someone else has already bought it. For example, two users buy the same "last item" at the same time because the stock was checked before it was updated.

• Shared resource: This occurs when multiple users or systems try to change the same data simultaneously without proper control. Since both updates happen together, the final result depends on which one finishes last, creating confusion. Think of two cashiers updating the same inventory spreadsheet at once, and one overwrites the other’s work.

• Atomicity violation: An atomic operation should happen all at once, either fully done or not at all. When parts of a process run separately, another request can sneak in between and cause inconsistent results. It’s like paying for an item, but before the system confirms it, someone else changes the price. For example, a payment is recorded, but the order confirmation fails because another request interrupts the process.

Mitigation

The attacker logged in and made a normal purchase of the limited SleighToy. Using Burp Suite, he captured the checkout request and sent it multiple times in parallel. Because the app didn’t handle simultaneous checkouts correctly, each request succeeded before the stock could update. This allowed the attacker to buy more toys than available, resulting in a race condition and pushing the stock into negative values. Here are a few mitigation measures to avoid the vulnerability:

• Use atomic database transactions so stock deduction and order creation execute as a single, consistent operation.

• Perform a final stock validation right before committing the transaction to prevent overselling.

• Implement idempotency keys for checkout requests to ensure duplicates aren’t processed multiple times.

• Apply rate limiting or concurrency controls to block rapid, repeated checkout attempts from the same user or session.

Answer the questions below

What is the flag value once the stocks are negative for SleighToy Limited Edition? THM{WINNER_OF_R@CE007}

Repeat the same steps as were done for ordering the SleighToy Limited Edition. What is the flag value once the stocks are negative for Bunny Plush (Blue)?

THM{WINNER_OF_Bunny_R@ce}