The Password Reset Feature – Changing your Password or Someone Else’s?
Most user-based web applications offer a password change or reset feature. When working correctly, it is an essential part of maintaining user accounts and keeping customers happy. However, a small misconfiguration within this key feature can result in the compromise of any user account.
A correctly configured password reset feature will verify if a user is authorized to change their password before executing the reset. Typically, this verification occurs through validating the user’s session cookie or authorization token.
Why Does it Matter?
Some applications instead rely on the username sent through a POST parameter to verify a user’s legitimacy. For example, the screenshots below show weak password reset requests:
The above requests rely on a ‘temp-forgot-password-token’ to verify that the user is authorized to perform a reset. However, when this token is sent empty the request is still successful, allowing an attacker to reset any user’s password simply by changing the username parameter.
Additional methods to manipulate password reset features through an email parameter can be seen below:
Password reset features are also commonly implemented through directly emailing users a password reset link. This link typically contains a token that is correlated to a user account. If an attacker can identify that the token uses weak entropy, is a hash of the user email, or is used repeatedly, it can likely be compromised and used to take over user accounts.
How Can You Fix It?
Password reset features are a common part of web applications. These features are typically unique to the application and require manual testing to determine if the business logic can be manipulated by an experienced attacker.
As a developer, it is best to ensure that users are properly authorized to reset an account password through their session token. Additionally, any tokens used in the reset process should be long and randomly generated.