Email Triggers
No Rate Limiting on Form which Triggers Emails
Overview of the Vulnerability
Rate Limiting prevents an application from becoming unresponsive or unavailable due to too many requests exhausting the application's resources. A lack of rate limiting on an email triggering endpoint was identified. This allows an attacker to create a large amount of emails to any email address, which they could use to spam a target with emails.
Business Impact
No rate limiting on a form which triggers email can result in reputational damage for the business as customers’ trust is impacted through receiving large amounts of unwanted and unsolicited emails. This also creates the risk of the email address domain being added to a spam list.
Additionally, for systems that use Software-as-a-Service (SaaS) email providers, there can be direct financial costs associated with sending large volumes of email.
Steps to Reproduce
Enable a HTTP intercept proxy, such as Burp Suite or OWASP ZAP, to record and intercept web traffic from your browser
Using a browser, sign into the application and navigate to {{url}}
Fill out the form that triggers an email, using an email that you own as the destination
Submit the form while using the HTTP intercept proxy to intercept the request
Using the HTTP intercept proxy, re-issue the captured request 400 times in rapid succession
Observe within the HTTP intercept proxy that all 400 of these requests triggered an email, showing that there is no rate-limiting on the form
Perform another, manual email triggering form submission in the browser without the interception proxy enabled
Observe that the form is submitted and an email is triggered successfully. This shows that there is no silent lockout implemented
Proof of Concept
The following screenshots demonstrate a lack of rate limiting on the email triggering 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 that multiple submissions of the form resulted in >400 emails being sent in rapid succession, failing to trigger any rate limiting by the application. 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.
Last updated