Guide 08 in Sarah’s Welcome to Web Security Series #

In this series, Sarah discusses some common vulnerability classes found in web security and how you can find and exploit them. Today’s focus is race conditions, a niche time-based attack vector that takes advantage of unsafe parallel program execution.

Introduction #

In and of themselves, race conditions are not necessarily a vulnerability. After all, a race condition is simply the name for “when two or more threads access some shared data and try to do something to it at the same time”. However, if a website processes some requests concurrently without sufficient defences, it can lead to some very interesting interactions (called “collisions”) which leads to unintended behaviour. That small window of time where collisions are possible is called a “race window” and these gaps can be very small, perhaps only a few milliseconds, which makes good use of tools and patience necessary.¹ Furthermore, race conditions have been around for a while, however, race conditions as a viable and not overly-complex web vulnerability is a more recent development. In fact, the researchers at PortSwigger were the ones to champion the idea with their article and presentation at Black Hat USA 2023.

Finding and Exploiting Race Condition Vulnerabilities #

There are actually a few ways race conditions can be exploited. The best-known variant involves exceeding a limit imposed by the logic of the application. Consider a shop that lets you use discount codes. If you enter a code, wait, and then enter it again, it will be rejected the second time because you have already used it (perhaps it has set up some flag in the back end). However, if you send ten requests at once, and the system begins processing them in parallel, then it may not realise that you are sending ten, identical codes and thus let you get a super-discount. Therefore, looking out for similar scenarios (i.e. scenarios where a system takes time to validate or authenticate something) may help you to find more vulnerabilities, though they are often hard to detect without manually trying a few attacks.

A second variant that is similar to limit overrun is called multi-endpoint race conditions. As you would imagine, it involves disrupting a logic flaw by sending some request at a non-standard time. Consider an online store that has a checkout system. If you could send the ‘basket confirmed’ request before your payment is validated, you would be able to get an item without paying for it. The challenge in this vulnerability is timing it, as the race window between validation and confirmation can be very small and you also have to take into account the speed at which different requests are processed.

Another, more complex variant arises from multi-step sequences. That is to say, a single HTTP request sets off a whole chain of requests in the background, processes them, and then returns something once all these hidden requests have been completed. In PortSwigger’s research, they call these hidden states “sub-states”. To exploit this vulnerability, an attacker would interfere with the sub-states by sending requests at certain points in time to cause unintended behaviour. However, it can be very challenging to find these vulnerabilities, particularly if you try to manually test every endpoint. Moreover, it takes a great deal of practice to recognise when a collision might be possible. Thus, this once again becomes a case of throwing pasta at the wall and seeing what sticks.²

This list is non-exhaustive as race conditions are still a relatively new concept. There are certainly more variants and ways to detect them, but these are just the most common. Therefore, just give it a try and see what happens. Perhaps you might even discover a new attack vector…

Defending Against Race Conditions #

Given how hard they are to detect, it can be challenging to effectively defend against race condition vulnerabilities. However, PortSwigger does offer some suggestions:

• Avoid mixing data
• Use datastore’s concurrency features if possible to protect sensitive endpoints
• Make sure your session handling framework keeps sessions internally consistent

As more race condition vulnerabilities are discovered, there is no doubt that researchers will find more ways to defend against them as well.

Conclusion #

As more cybersecurity professionals become aware of the possible exploits that can make use of race conditions, we may realise that they are a lot more common than initially anticipated. After all, they are somewhat similar to business logic flaw vulnerabilities, which are also reasonably common. However, they can be difficult to detect and exploit, often requiring a great deal of patience. Nevertheless, if you are interested in race conditions, you should check out PortSwigger’s excellent page on it.

If you are interested in learning more about race conditions and web security, the WebSecurity Academy is a fantastic resource. You can create a free account and explore their labs here.