What are Race Conditions?
Race conditions, or condiciones de carrera, represent a vulnerability that arises when the behavior of a system depends on the order or synchronization of multiple concurrent operations. This occurs when the server processes requests simultaneously without implementing the appropriate protection mechanisms (safeguards), which can lead to inconsistencies, unexpected errors, or even critical failures in the security of the system.
All of this happens when there is an absence of adequate control mechanisms and these operations can interfere with each other, causing unexpected behaviors, errors, or even critical failures in the security and stability of the system.
This type of vulnerability is especially common in multithreaded environments or distributed systems, where multiple processes simultaneously access shared resources without the necessary guarantees of consistency and control.
Let’s look at an example to make it easier to understand.
In a banking application, if two users try to transfer funds from the same account at the same time and there is no proper synchronization, the final balance could become outdated or incorrect. This vulnerability can be exploited by attackers to obtain illicit benefits or compromise the integrity of the system.
Another concept that is important to understand is the Race Window.
The Race Window is the brief period of time in which collisions or interferences between concurrent operations can occur. During this period, which may last only fractions of a second, multiple interactions, such as queries or modifications to a database, can be executed without proper synchronization. This opens the door to race conditions and potential security issues.
The attack may not work or be successful on the first attempt, since synchronizing multiple requests within the race window is a complex process. For this reason, it is necessary to try several times until the requests are executed at the precise moment needed to exploit the vulnerability.
Exploitation in HTTP/1 and HTTP/2
Web applications that use the HTTP/1 and HTTP/2 protocols can be particularly vulnerable to race conditions.
In HTTP/1, requests are handled sequentially. At first glance, this might seem like an advantage in terms of security, since each request is processed in order and there is no direct concurrency. However, an attacker can exploit this vulnerability by sending multiple requests in a short period of time.
The problem lies in the fact that, although the requests are executed one after another, the server may not update its state quickly enough between one request and the next. This opens the door to attacks that take advantage of these intermediate states, which can lead to unexpected behaviors or the leakage of sensitive information. In vulnerable scenarios, an attacker could modify data in one request and, before the server fully reflects the change, send another request that leverages the inconsistent state.
HTTP/2 introduced request multiplexing, a key improvement for performance. This feature allows multiple requests and responses to travel simultaneously over a single TCP connection, eliminating head-of-line blocking and reducing latency. However, this improvement in efficiency also expands the attack surface.
By allowing greater concurrency, HTTP/2 makes it easier for attackers to design scenarios in which multiple requests are processed simultaneously. This increases the chances of exploiting race conditions, as the server may be forced to handle inconsistent states when processing multiple requests in parallel. An attacker could, for example, take advantage of this simultaneity to modify critical data before another request validates it or uses it in a sensitive operation.
Common Types of Attacks Based on Race Conditions
▪️ Limit Overrun Exploitation
Limit overrun occurs when an attacker forces a system to process more requests, data, or resources than it is designed to handle. For example, if an application allows each user to redeem a coupon only once, an attacker could exploit this logic by sending multiple requests simultaneously, managing to use the coupon several times before the database updates the information.
▪️ Authentication Sequence Evasion (Hidden Multi-Step Sequences)
In systems that require several consecutive steps, such as multifactor authentication, attackers can take advantage of failures in the process between one step and another. For example, in a system that sends a verification code to the mobile phone, an attacker could exploit the time in which the system has not yet validated the information to try to bypass part of the security procedure.
▪️ Race Conditions in Multiple Access Points (Multi-Endpoint Race Conditions)
When different endpoints interact with the same shared resources without proper synchronization, attackers can manipulate data or bypass restrictions. A common example is when different APIs allow modifying the same resource without centralized control.
An example of this could be adding products to the cart after checking the available balance in the account.
▪️ Race Conditions in a Single Access Point (Single-Endpoint Race Conditions)
These occur when multiple requests are sent simultaneously to the same access point, such as a web page or an API endpoint. This happens, for example, in a password reset mechanism where two parallel requests are sent with different users, which could allow an attacker to obtain a valid reset token for someone else’s account. Another example is when two simultaneous requests to modify a shared resource can overwrite each other’s changes.
▪️ Time-Based Race Condition Attacks (Time-of-Check to Time-of-Use – TOCTOU)
TOCTOU (Time of Check to Time of Use) attacks exploit the time window between the verification and the use of a resource. Let’s use an example to make it easier to understand: imagine an application checks permissions before opening a file; an attacker could replace that file before the operation is completed.
Mitigations and Best Practices to Prevent Race Conditions
To mitigate or prevent this vulnerability, the following should be taken into account:
▪️Control of Access to Shared Resources:
Instead of allowing multiple processes to modify data at the same time, mechanisms should be implemented so that only a single process can access the resource at any given moment.
An example of this is setting up a waiting queue so that each process waits its turn before modifying the data.
▪️ Protected Code Zones (Critical Sections):
Parts of the code are identified where only one process at a time can modify information. If another process tries to access that part of the code while it is already in use, it must wait until the first one finishes.
▪️ Change Confirmation Systems (Transactional Memory):
Instead of modifying data directly, changes are made provisionally and are only applied if there was no interference from another process at the same time. If there is a conflict, the changes are rolled back and the operation is attempted again.
▪️ Use of Specially Protected Variables:
There are variables designed to ensure that, when they are modified, there are no interruptions from other processes. It is like an electrical switch: when one process changes it, it cannot be changed by another until the first one has finished. This prevents two processes from trying to modify the same information at the same time.
▪️ Control in Databases:
For systems that handle stored information, it is essential to use security levels in transactions to prevent two processes from altering data incorrectly at the same time.
Rules such as “wait before writing if someone else is reading” can be applied to avoid conflicts.
The key here is that, to avoid race conditions, it is important to properly organize access to shared data, ensuring that each process waits its turn or has its own copy of the information whenever possible.
References:
All images have been obtained from:
https://portswigger.net/web-security/race-conditions
