Password Reset Poisoning Scanner
Tests for host header poisoning in password reset flows.
What is Password Reset Poisoning?
Password Reset Poisoning occurs when an application uses the Host header from the HTTP request to generate password reset links. Attackers can manipulate the Host header to create reset links pointing to their own domain, capturing reset tokens when victims click the malicious links.
Why is This Important?
This vulnerability enables account takeover without any access to the victim's email. When the victim receives a legitimate-looking reset email and clicks the link, the token goes to the attacker instead of the real application. The attacker then uses the token to reset the password and take over the account.
How It Works
1. Auth Flow Analysis
Maps authentication mechanisms including login, registration, password reset, and session management flows.
2. Security Testing
Tests for authentication bypasses, weak credentials, session flaws, and token vulnerabilities.
3. Access Verification
Validates findings by demonstrating unauthorized access or privilege escalation paths.
Key Capabilities
Comprehensive authentication security testing to protect user accounts and prevent unauthorized access.
- Complete authentication flow analysis
- Token and session security validation
- Password policy and brute-force testing
- Multi-factor authentication bypass detection
- OAuth, SAML, and JWT security assessment
Frequently Asked Questions
How does password reset poisoning work?
1) Attacker requests password reset for victim's email with malicious Host header. 2) Server generates reset link using attacker's host. 3) Victim receives email with link to attacker's domain. 4) Victim clicks, token sent to attacker. 5) Attacker uses token on real site to reset password.
What headers can be manipulated?
Host header is primary target, but also check: X-Forwarded-Host, X-Host, X-Forwarded-Server, X-HTTP-Host-Override, X-Original-URL, X-Rewrite-URL, and combinations. Some apps trust various headers from reverse proxies without validation.
Why do applications trust the Host header?
Applications need to generate absolute URLs for emails but may not have the correct host configured. Developers assume Host header is trustworthy (it's not). Legacy applications predate awareness of this attack. Frameworks may provide URL generation that uses Host by default.
How do I prevent password reset poisoning?
Never use Host header for URL generation, configure the application's base URL explicitly, validate Host header against a whitelist, use relative URLs where possible, add CSRF protection to reset forms, and consider dangling markup protection in emails.
Related Scanners
Ready to secure your application?
Start testing for password reset poisoning vulnerabilities today.
Get Started Free