No Rate Limit: The Easiest Bug Bounty Payout You’re Missing

2 days ago 10
BOOK THIS SPACE FOR AD
ARTICLE AD

Rate limiting is a common security control used by developers to prevent abuse, brute-force attacks, and API misuse. However, misconfigurations where no rate limit is implemented can lead to serious vulnerabilities, allowing attackers to perform account takeovers, scrape data, or exploit business logic flaws.

For bug bounty hunters, no rate limit vulnerabilities are some of the easiest and most rewarding bugs to find.

When applications fail to enforce rate limiting, attackers can send unlimited requests without any restrictions. This is commonly found in:

Login Forms (leading to brute-force attacks)Password Reset & Account Recovery2FA & OTP ValidationAPI Endpoints (leading to mass data extraction)Sensitive Actions (such as money transfers, coupon redemption, etc.)

LETS DIVE INTO IT UwU

We will be finding no rate limit vulnerability and in order to do so we need a target and in my case ill be showcasing no rate limit vulnerability i found on my client web portal on send otp funtionality however generally you will need a target and burp suite to test no rate limit.

CASE SCENERIO:

The website was sending a request for generating and sending OTP. We captured that request and it had a account number parameter, we will be using that to test no rate limit.

STEPS:

Fire up burp suite

setup proxy to capture traffic

identify target such as login functionality, reset password or send otp functionality. In our case its OTP functionality.

send the request, for example: send otp or login using random credentials etc.

capture the request

send the request to intruder and identify the parameter for payload position

Here we are using account number parameter and adding our payload position in the end of payload.

We will select payload type to null payload so that it does not add anything in parameter value except for null values ( nothing ). We are doing so to send unlimited OTP that will lead to

Resource ExhaustionFlood users emails and text messages with OTPs

Next we are going to verify if its vulnerable and does not have rate limitting. Start the attack and observe

As we can see over here that all the requests are going through and giving a response code 200 and in response there is a success parameter value too pointing that otp was successfully sent. This proves that vulnerability exists.

Read Entire Article