Week 54 - Race Conditions

This week’s web hacking tip is on Race Conditions!

When discussing these vulnerabilities, I’ve found that students can often get confused or have difficulty describing them. Personally, I find the following example helpful:

Let’s say we are working with a website that uses gift cards at checkout. When a gift card is submitted by a user, the back-end server checks whether the code is valid or not. If it’s valid, the balance is added to the user’s account. If not, an error message is displayed.

Now, race conditions occur within features that limit the number of times you can perform an action. In the gift card example above, we should only be allowed to submit a valid gift card code one time. The key here is, in the time the back-end server takes to validate the gift card code and mark it as used, we may be able to send multiple concurrent requests that will successfully go through.

TL;DR: Send concurrent requests to the server with a valid gift card code, in an attempt to execute multiple requests before the server has time to mark the gift card as previously used.

So, how can you send multiple concurrent requests? I recommend using either a Python script (asyncio and httpx libraries) or BurpSuite’s Turbo Intruder extension.

How can you prevent Race Conditions? If your application is multi-threaded, use locks on potentially vulnerable functions and actions. Locks work to ensure that operations occur in order (synchronously), so threat actors can’t take advantage of them by flooding requests.