Finding Bugs Beyond the Obvious: A Rate Limit Bypass Story

Hello everyone! Welcome to my blog, where I’ll share a unique finding from my bug bounty journey.

Bug bounty hunting is an art — an art of finding vulnerabilities through unique and innovative techniques. It’s not just about following a checklist; it’s about using your mind to think creatively, to explore possibilities others might overlook. It’s the ability to say, “What else can I try?” and follow different paths. The true essence lies in finding vulnerabilities that remain hidden from others and pushing boundaries with curiosity, determination, and cleverness.

Why I Think Bug Bounty Hunting is an Art:

I had to tell you about why bug bounty is an art: it is because most of the time people overlook common bugs that are in front of them, but due to their lack of focus, they are unable to find these kinds of vulnerabilities. Don’t just blindly follow other people’s methodology. It might have worked for them, but it is not a guarantee that it will work for you. Create your own workflow.

It would take an entire blog to talk about the mindset and mentality one should have while hunting for bugs — but that’s a topic for another time.

For now, let’s jump straight into it. I’ll dive right into the finding and skip explaining what a rate limit bypass is. Come on, guys, Google it if you don’t already know!

So, it’s a program on HackerOne that I had been hunting on for a while. I decided to check if there was any rate limit implemented on the login page of the web application.

Step 1: Watching How the App Behaves

I Cold started my Burp and went through the login process to understand the application’s behavior. First, I logged in using the correct credentials and then logged out. After that, I tried logging in again with incorrect credentials to observe how the application responded. Throughout this process, Burp Suite was capturing all the requests and responses in the HTTP History tab, which I planned to use for further analysis of the functionality.

Step 2: Analyzing Error Messages

The first thing I always try to notice is the error message the application displays when incorrect input is given. Does it say, ”Either Username or Password is incorrect” or something like ”The Password you entered is incorrect” for the correct username and wrong password? Many people don’t realize how important it is to pay attention to these subtle details when testing for vulnerabilities.

A vulnerability can even arise from error messages, and I’ll show you what I mean.

Error Messages Can Leak Information:
1. If the application displays ”The Password you entered is incorrect”, it confirms the username is valid.
2. This allows attackers to directly brute-force the password without username enumeration.Generic Error Messages Add Security:
1. Messages like ”Either Username or Password is incorrect” make it harder for attackers to identify which input (username or password) is invalid.
2. Always test how the application handles and displays error messages during input validation.

Breaking Down the Vulnerability

There were two endpoints:

- target.com
- auth.target.com

After five unsuccessful attempts, the application responded with ”We have received too many requests. Please try again later.” This message clearly indicates that some kind of rate limit is implemented. So now, let’s try to analyze how things are working behind the scenes.

I noticed that to authenticate a user, the application makes an request from target.com → auth.target.com for validation of the user’s credentials. So, on my Burp Suite, I sent the request from auth.target.com to the Repeater and started analyzing it.

I removed all unnecessary headers and cookies while ensuring it didn’t affect the response. By doing this, I quickly identified which headers and cookies were responsible for maintaining the session and which were responsible for rate limiting.

I forwarded the request to Intruder and started a brute force attack.
I noticed a very strange behavior in the application:

Inconsistency in server-side rate limiting.Due to this inconsistency, even after multiple failed login attempts, it returned 200 OK, indicating the credentials were correct.It also returned 400 Bad Request for correct credentials, asking for a 2FA code that the application had sent to the victim’s email.

Let’s discuss these points one by one.

1. Inconsistency in Server-Side Rate Limiting:

As mentioned earlier, the target.com UI properly implemented rate limiting after five unsuccessful attempts, but things on auth.target.com weren’t the same. If you look at the above snapshot, you’ll notice a lot going on. After five unsuccessful attempts, the application should continue to apply rate limiting to all subsequent requests. However, due to a misconfiguration in the backend, it was unable to implement this correctly.

2. Inconsistency Causing a `200 OK` After Multiple Failed Attempts:

Since the server failed to properly apply rate limiting on auth.target.com after five unsuccessful attempts, it returned a 200 OK response for the correct credentials. This response gave us the access_token and id_token required to log in successfully.

3. `400 Bad Request` Requesting 2FA Code Sent to Victim’s Email:

While brute-forcing, I noticed 2 things:

400 Bad Request for all the other incorrect requests, due to the inconsistency in rate limiting.400 Bad Request for correct credentials asking for a 2FA code, confirming that the credentials are correct.

The application returned a 400 Bad Request, along with an error stating that an OTP was required for validation, which had been sent to the victim’s email. This might look like an error, and many people may ignore it, but what hunters often don’t realize is that this error actually indicates the credentials are valid. It’s clear the application is sending an OTP because the credentials were correct.

Now, you might ask, how did I know there was a response confirming that the credentials were actually correct among so many other 400 Bad ones? Well, I didn’t just rely on the status codes—I was also checking the length of the responses to see if there were any unique ones with different response lengths.

Lessons From This Bug

This experience reminded me why bug hunting is always exciting. It’s not just about writing a perfect PoC, it’s about thinking outside the box and noticing patterns. Here’s what I took away (and hopefully, you will too):

Error Messages Are Gold: The smallest details can give away so much. Pay attention to them.Test Frontend and Backend Separately: Just because the frontend has a restriction doesn’t mean the backend does.Don’t Brush Off Errors: What may seem like a random error could be the key to finding a bug.

Wrapping It Up

Bug bounty hunting is a mix of persistence, curiosity, and good old trial and error. Each bug you uncover feels like cracking a puzzle — and the rush when you find one? There’s nothing like it.

If you made it this far, thanks for reading! Hope this write-up gave you some insight into how I approach bug hunting, and maybe even sparked some ideas for your next hunt.

Happy hunting, and always ask yourself — “What if…?”

My Social media handles:

Twitter/XLinkedin