Advent of Cyber 2025 - Day 20 - Race Conditions - Toy to The World

Exploiting Race Conditions in Web Applications

Day 20 – TryHackMe | The Best Festival Company (TBFC)

Introduction

The Best Festival Company (TBFC) released a limited-edition SleighToy, with only 10 units available at midnight. But more than 10 customers received order confirmations. How did this happen?

McSkidy discovered that several buyers completed purchases simultaneously, exploiting a tiny timing flaw in the system. The Bandit Bunnies sent multiple rapid checkout requests, showing how milliseconds can affect web applications.

---

Learning Objectives

After completing this task, you will understand:

• What race conditions are and their impact on web applications

• How attackers exploit race conditions using concurrent requests

• How shared resources like stock values can be manipulated

• Techniques to prevent race condition vulnerabilities

---

What Is a Race Condition?

A race condition occurs when two or more operations happen at the same time, and the final outcome depends on their order of completion.

In web applications, race conditions often appear when:

• Multiple users access the same resource simultaneously

• Stock, balances, or sessions are not properly synchronized

This can result in:

• Oversold products

• Duplicate transactions

• Unauthorized or inconsistent data changes

---

Types of Race Conditions

1. Time-of-Check to Time-of-Use (TOCTOU)

   • System checks a condition (e.g., stock availability)

   • Uses it later, after the data changes

   • Example: Two users see “1 item left” and both purchase successfully before the stock updates

2. Shared Resource Race Condition

   • Multiple processes update the same data at the same time

   • Example: Two cashiers updating the same inventory file simultaneously

3. Atomicity Violation

   • An operation that should occur all at once is interrupted

   • Example: Payment is recorded but order confirmation fails due to overlapping requests

---

Exploiting the Race Condition (Hands-on)

Environment Setup

• Firefox traffic routed through Burp Suite

• Burp Proxy: Intercept OFF

• Login credentials:

  • Username: attacker

  • Password: attacker@123

Steps

1. Make a Legitimate Purchase

   • Add SleighToy Limited Edition to the cart

   • Click Checkout → Confirm & Pay

   • Observe successful order confirmation

   • Generates a POST request to /process_checkout

2. Capture and Replay Requests

   • Open Burp Suite → Proxy → HTTP History

   • Send the POST request to Repeater

   • Duplicate request 15 times

   • Send all requests in parallel

Result

• All requests succeed

• Stock value drops below zero

• Multiple orders are confirmed

• Race condition confirmed

---

Flags Obtained

• SleighToy Limited Edition: THM{WINNER_OF_R@CE007}

• Bunny Plush (Blue): THM{WINNER_OF_Bunny_R@ce}

---

Mitigation Techniques

To prevent race conditions:

• Use atomic database transactions

• Validate stock before committing orders

• Implement idempotency keys for checkout requests

• Apply rate limiting and concurrency controls

• Lock shared resources during critical operations

---

Conclusion

This task shows how concurrent requests can break application logic when synchronization is missing. A few milliseconds can oversell stock and cause chaos.

Race conditions are subtle but dangerous. Understanding how to detect, exploit, and prevent them is critical for both developers and security analysts.

For more hands-on practice, check out the Race Conditions room on TryHackMe 🔐🚀