|
Task Description
### Summary
The password-reset endpoint at `https://admin.alwaysdata.com/password/lost/` appears to rely on the client-supplied `X-Forwarded-For` header when identifying clients for rate limiting.
After reaching the endpoint's request limit and receiving an HTTP `429 Too Many Requests` response, changing the `X-Forwarded-For` header value allowed additional password-reset requests.
During testing using my own email address, I received nearly 100 password-reset emails, demonstrating that the rate-limiting mechanism could be bypassed and that repeated email notifications could be triggered.
### Affected Endpoint
`POST https://admin.alwaysdata.com/password/lost/`
### Steps to Reproduce
1. Navigate to the password-reset page.
2. Submit password-reset requests using an email address you control.
3. Continue until the server responds with `HTTP/2 429 Too Many Requests`.
4. Change the `X-Forwarded-For` header value in the request.
5. Submit another request.
6. Observe that the endpoint accepts further requests despite the previous rate-limit response.
7. Check the controlled mailbox and observe the additional password-reset emails.
### Proof of Concept
Original request header:
`X-Forwarded-For: [initial value]`
After receiving HTTP 429, change the header:
`X-Forwarded-For: [different value]`
The endpoint then accepts further requests instead of consistently enforcing the rate limit.
### Impact
An unauthenticated attacker may be able to bypass the password-reset request limit by manipulating the `X-Forwarded-For` header.
This could allow repeated password-reset emails to be triggered for a target email address, potentially resulting in email flooding, user disruption, and abuse of the password-reset notification system.
Testing was performed only using an email address under my control.
### Recommended Remediation
- Do not trust arbitrary client-supplied `X-Forwarded-For` values.
- Configure trusted reverse proxies to overwrite or sanitise forwarding headers.
- Derive the rate-limit identity from the actual client IP as established by trusted infrastructure.
- Apply additional rate limits based on the destination email address and other appropriate identifiers.
- Consider a progressive cooldown and abuse-detection mechanism.
### Evidence
- HTTP 429 response showing that the rate limit was reached.
- Subsequent accepted requests after changing the forwarding header.
- Password-reset emails received in my controlled mailbox, with timestamps.
|
