Race conditions occur when web applications process requests concurrently without adequate safeguards. This can lead to multiple distinct threads interacting with the same data at the same time, resulting in a “collision” that causes unintended behavior in the application. A race condition attack uses carefully timed requests to cause intentional collisions and exploit this unintended behavior for malicious purposes.
- Race conditions (PortSwigger)
- Sending grouped HTTP requests (PortSwigger)
- CWE-362 (MITRE)
Limit overrun
Limit overruns are a subtype of time-of-check to time-of-use (TOCTOU). They enable you to exceed some kind of limit imposed by the business logic of the application. Examples:
- Redeeming a gift card multiple times
- Rating a product multiple times
- Withdrawing or transferring cash in excess of your account balance
- Reusing a single CAPTCHA solution
- Bypassing an anti-brute-force rate limit
Detection
- Identify a single-use or rate-limited endpoint that has some kind of security impact or other useful purpose.
- Issue multiple requests to this endpoint in quick succession to see if you can overrun this limit.
Testing
- From the Repeater, right-click on the request and click Add tab to group -> Create tab group. Choose a name like “Race condition”.
- Right-click on the request in the Repeater and Send to Repeater again in the same tab group. Do the same step as needed.
- Click on the first request, click on the arrow beside Send and select Send group in parallel (single-packet attack).
- Click on Send group (parallel).
- Validate if the action worked multiple times (like redeeming a gift card). You may need to resend the requests a few times.