Breaking the Rules: How a Race Condition Allowed Me to Bypass the Limits

Back in February, while most people were looking for love, I was on a different mission: trying to find race conditions and HTTP request smuggling vulnerabilities.

I was obsessed with finding at least one race condition or a HTTP request smuggling vulnerability after watching the GOAT of security research Albinowax’s Black Hat videos.

I didn’t find any valid HTTP request smuggling bugs, only a lot of false positives but I did manage to find a Race condition.

At first I was trying to apply it in the promo codes and discount coupons of online commerce websites like in the web security academy lab but they were all using the same framework which was not vulnerable. Then I started applying it wherever there’s a limit and I finally found it.

The app lets you say ‘Thanks’ to your friends but you can only send 2 same type of Thanks(there are many types of thanks) in a month.

So I finished my 2 attempts of Thanks(type A) and sent a third one and the response was “you have exceeded your attempts of Thanks(type A) for the month”.

Now I sent a Thanks(type B) and intercepted the API request and sent it to the Repeater. Duplicated the request 20 times and added all the tabs to a group.

Set the Group send options to “single-packet attack” and sent it.

Out of 20 requests, 11 returned a 200 Success status. The other 9 requests were blocked as they missed the race window and returned the error.

The race window in this functionality would be the time between:

By grouping requests into a single-packet attack, all requests hit the server at the same time, bypassing the server’s ability to update the count and restrict in real-time. Some requests were processed before the app could update the count, allowing me to bypass the monthly limit.

The app displayed “Awards remaining: -9” because I managed to send 11 ‘Thanks’, which was 9 over the monthly limit of 2.

This is just a cool bug, there’s no real impact to the Business because of this vulnerability. But hey a win is a win.

These vulns were reported to the company’s Private VDP

I also found a Stored XSS and an IDOR leaking PII in the same site.

Payload: <script>alert(1)</script>

The IDOR was just another sequential numerical IDOR leaking Email ID, phone number and Location.

Apologies for the quality of the POCs. I wasn’t good at taking POCs back in February.