testing-password-reset-flaws

Send the forgot-password request with a spoofed Host or X-Forwarded-Host header pointing to an attacker-controlled domain, then inspect the emailed reset link. If the link points to your domain, the victim's token is delivered to you when they click, enabling account takeover.

Request many resets rapidly and compare the tokens for incrementing counters, timestamps, or short character sets. Use Burp Sequencer to measure statistical entropy across captured samples, and test whether tokens are hashes of known values like email addresses.

Burp Suite Professional with Repeater, Intruder, and Sequencer covers interception, fuzzing, and token entropy analysis. You also need curl for manual header injection, a Burp Collaborator or catch-all domain to observe poisoned links, and two test accounts with accessible inboxes.

Yes, when the reset confirm endpoint trusts a client-supplied user, email, or user_id parameter instead of binding the token to the account server-side. Submit your own valid token with the victim's identifier swapped in, then confirm by logging in as the victim.

If sessions are not invalidated after a password change, an attacker holding a previously stolen session cookie retains access even after the victim resets their password. Test by replaying a pre-reset session cookie against an authenticated endpoint after completing the reset.

Only use it with written authorization for the target application, such as a penetration testing agreement or bug bounty scope. It targets web-based reset flows and does not cover offline credential attacks or non-HTTP recovery mechanisms.