Single Endpoint Race Conditions

Sending parallel requests with different values to a single endpoint can sometimes trigger powerful race conditions.

Consider a password reset mechanism that stores the user ID and reset token in the user's session.

In this scenario, sending two parallel password reset requests from the same session, but with two different usernames, could potentially cause the following collision:

Source: https://portswigger.net/web-security/race-conditions

Note the final state when all operations are complete:

• session['reset-user'] = victim

• session['reset-token'] = 1234

The session now contains the victim's user ID, but the valid reset token is sent to the attacker.

For this attack to work, the different operations performed by each process must occur in just the right order. It would likely require multiple attempts, or a bit of luck, to achieve the desired outcome.

Email address confirmations, or any email-based operations, are generally a good target for single-endpoint race conditions. Emails are often sent in a background thread after the server issues the HTTP response to the client, making race conditions more likely.

Methodology

• Try to change the email address and send the request to burp repeater

• Create another request and change the email to that of your victim

• Add both the request into a single group

• Send the request as a parallel request

• View your email client

• This should give you a link to change the email to that of your victim account

You may need to perform this task multiple times

---

REFERENCES

• https://portswigger.net/web-security/race-conditions

• https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint