- by x32x01 ||
A password reset feature can become a serious security risk if reset tokens are not properly tied to the account they belong to.
During security testing, I discovered an Account Takeover (ATO) vulnerability in a password reset flow that allowed an attacker to change a victim's password by modifying the email address submitted with the reset request.
Normally, the user opens this link and enters a new password through the application's interface.
However, while inspecting the password reset process using Burp Suite, I noticed something interesting.
The interface only asks for a new password, but the actual HTTP request also includes:
The application accepted the modified email address without verifying that it belonged to the account associated with the reset token.
In other words, the reset token was not properly bound to the original account identity.
As a result, the application allowed the password reset operation to target a different account.
Never trust an email address or account identifier supplied by the client when processing a password reset.
Even a seemingly simple parameter validation issue can turn a normal password reset feature into a full Account Takeover vulnerability.
During security testing, I discovered an Account Takeover (ATO) vulnerability in a password reset flow that allowed an attacker to change a victim's password by modifying the email address submitted with the reset request.
🔍 How the Vulnerability Works
When a user requests a password reset, the application sends a link containing a reset token, such as: Code:
https://TARGET/users/password/edit?reset_password_token=REDACTEDHowever, while inspecting the password reset process using Burp Suite, I noticed something interesting.
The interface only asks for a new password, but the actual HTTP request also includes:
- The password reset token.
- The new password.
- The account's email address.
⚠️ The Security Flaw
During testing on an authorized target, I modified the email address in the password reset request to another account's email address.The application accepted the modified email address without verifying that it belonged to the account associated with the reset token.
In other words, the reset token was not properly bound to the original account identity.
As a result, the application allowed the password reset operation to target a different account.
💥 Security Impact
If successfully exploited, this vulnerability could allow an attacker to:- Change another user's password.
- Take complete control of the victim's account.
- Access private account information.
- Impersonate the victim.
- Potentially access other services or data linked to the compromised account.
🛡️ How to Prevent This Vulnerability
Developers should follow these security practices when implementing password reset functionality:- Bind tokens to accounts: Associate every reset token with a specific user ID, not an email address supplied by the client.
- Ignore untrusted identity parameters: Never allow the client to choose which account receives a password reset through a modifiable email parameter.
- Validate tokens server-side: Verify that the token belongs to the intended account and is valid for the requested operation.
- Use single-use tokens: Invalidate reset tokens immediately after a successful password change.
- Set token expiration: Reset tokens should have a short, clearly defined lifetime.
- Prevent token reuse: Ensure expired, consumed, or invalidated tokens cannot be used again.
💡 Key Takeaway
A password reset token must always be tied to the account for which it was originally generated.Never trust an email address or account identifier supplied by the client when processing a password reset.
Even a seemingly simple parameter validation issue can turn a normal password reset feature into a full Account Takeover vulnerability.