All Projects

Hi Sir,

i am a Security researcher and a full time bug hunter i saw your bug
bounty program so i decided to test some vulnerability and i got No
Rate limiting on login form

here is the brief introduction of my bug please have a look

Severity = 6.5 to 7.5 (Medium to High)

(*) What is No Rate Limiting on the Login Form?

Rate limiting is a security measure that restricts the number of
requests a user can make to a server or system in a defined time
period. It helps mitigate brute force attacks by limiting the number
of login attempts a user can make in a short time frame.

When no rate limiting is applied to a login form, an attacker or
malicious user can send an unlimited number of requests, trying
various combinations of usernames and passwords. This could result in
unauthorized access or application-level denial of service (DDoS)
attacks if abused.

Overview of this Vulnerability During testing of the login functionality, I discovered a rate limiting bypass based on HTTP method manipulation. While the application initially enforced rate limiting when using the PUT method, switching the request method to PUT allowed me to bypass this protection entirely. Using the PUT method, I was able to send over 2,000 login requests without triggering any rate limiting mechanisms such as throttling, CAPTCHA, or account lockout. This confirms that the rate limiting controls are not consistently enforced across different HTTP methods. As a result, the application is exposed to brute force, credential stuffing, and denial-of-service attacks, allowing attackers to automate large-scale login attempts without restriction. Impacts

(1) Brute Force & Credential Stuffing Attacks:

Without rate limiting, attackers can try an unlimited number of
password combinations against the login form. This allows for brute
force or credential stuffing attacks, where an attacker can automate
the process of trying stolen or commonly used passwords for a given
username. With no restrictions on the number of login attempts, it
significantly increases the chances of gaining unauthorized access to
user accounts

(2) Account Takeover (ATO) Risk:

The absence of rate limiting makes it easier for attackers to gain
access to user accounts by attempting multiple password combinations.
Once an attacker successfully cracks a password, they can take over an
account and perform malicious actions, such as stealing sensitive data
or making unauthorized transactions.

(3) Denial of Service (DoS) or Application-Level DDoS:

The lack of rate limiting on the login form means that the server can
be overwhelmed with a high volume of requests. Attackers can flood the
login page with thousands of requests, leading to potential server
downtime or slowdowns. This can prevent legitimate users from
accessing the site, degrading the user experience and disrupting
normal service operations. It can also lead to increased server load
and higher operational costs.

(4) Increased Attack Surface for Automated Tools:

Automated tools like Burp Suite Intruder or Hydra can easily exploit
the lack of rate limiting, allowing attackers to test massive amounts
of login credentials in a short period of time. This increases the
risk of automated attacks, as attackers can use these tools to exploit
the vulnerability without manual intervention.

(5) Loss of Trust and Reputation:

If attackers are able to successfully break into accounts due to the
lack of rate limiting, it can lead to a loss of trust among users. If
users discover that their accounts can be easily compromised, it could
damage the reputation of the service or platform, leading to reduced
user engagement and retention.

Steps to reproduce (1) Navigate to the url https://translate.alwaysdata.com/login/?next=/ (2) Configure Burp Suite or any proxy tool (such as FoxyProxy in
Firefox) to intercept the HTTP request. (3) Attempt to log in with invalid credentials:
Submit a login attempt using incorrect username/password. Intercept this request and send it to Burp Repeater. (4) Send the same request multiple times in Repeater:
Continuously send the POST request.
After a certain number of requests, you’ll observe a 429 Too Many Requests response, confirming that the server has rate limiting in place for POST requests. (5) Modify the request method from POST to PUT in Repeater: Change the HTTP method from POST to PUT (keeping the same endpoint and parameters). Send the modified request and observe the 403 Bad Request response. (6)Send the modified PUT request to Burp Intruder: After modifying the method to PUT, send the request to Burp Intruder to test it with a wordlist.
Load a wordlist (e.g., Word.txt). (7) Send 2,000+ requests: I sent over 2,000 requests with invalid credentials and continued to receive HTTP 403 responses, confirming that rate limiting was bypassed and there were no restrictions for GET requests. (8) Observe Results: The system did not trigger any lockouts, CAPTCHAs, IP blocks, or delays between requests, confirming the absence of rate limiting on the PUT method. Proof of Concept (PoC)

i am providing some videos and screenshot of this vulnerability as proof of concept for this vulnerability

refer this link for all the pocs = https://drive.google.com/file/d/17NAxfE1BfyapBJuy3mCq01b47iBR3zCQ/view

I will be waiting for your reply team

Regards,
Sudo
Security researcher / Bug Hunter