No Rate Limiting on Form

No Rate Limiting on Form

Overview of the Vulnerability

Rate limiting is a strategy to limit the frequency of a repeat action within a particular time frame. This ensures that a service doesn’t become unresponsive or unavailable due to too many requests exhausting the application's resources. A lack of rate limiting on this endpoint allows an attacker to send a large number of requests to the server and potentially cause accelerated service usage for the business or exhaust the application resources.

Business Impact

No rate limiting on a form can result in reputational damage to the organization if the rate limiting prevents legitimate form submissions and responses. It also has the potential to cause accelerated service usage, which can incur a direct financial cost in environments with SaaS services or pay on demand systems.

Steps to Reproduce

1. Enable a HTTP intercept proxy, such as Burp Suite or OWASP ZAP, to record and intercept web traffic from your browser

2. Using a browser, navigate to {{url}}

3. Fill out the form and submit the form while using the HTTP intercept proxy to intercept the request

4. Using the HTTP intercept proxy, re-issue the captured request 400 times in rapid succession

5. Observe within the HTTP intercept proxy that all 400 of these requests generate a ‘HTTP 200 OK’ response, showing that there is no rate-limiting on the form

6. Perform another, manual form submission in the browser

7. Observe that the form is submitted successfully which shows that there is no silent lockout implemented

Proof of Concept

The following screenshots demonstrate a lack of rate limiting on the login form followed by a successful form submission:

{{screenshot}}

Guidance

Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed triage time and result in faster rewards.

Include a screenshot showing >400 submissions of the form in rapid succession, failing to trigger any rate limiting by the application. This must be followed with proof of the successful exploitation of the form (e.g. a successful login shown after 400 failed attempts). This demonstrates that there is no silent lockout occuring. Do not use an IP rotation utility in attempt to bypass existing IP-based rate limiting controls. Any submission that rely on IP rotation will not considered for a reward.

Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept.

Recommendation(s)

It is recommended to implement rate limiting on the form. This could include a CAPTCHA that a user has to solve before submission, or it could be enforcing a limit on the amount of submissions per minute, based on IP address.

For more information, please see Open Web Application Security Project (OWASP): https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html#rate-limiting