This blog post is about a recent web application penetration test in which we identified an insecure password reset functionality. We will walk through the password reset functionality, identify what went wrong, and provide suggestions for remediating this issue.
Reset Process
Navigating to the reset password page, the user can enter in their email to receive a password reset link:
After receiving the password reset email, the user then clicks the given link within the email and is directed out to the following page to reset their password:
Where did the process go wrong?
Let’s take a look at the HTTP requests that are made during the password reset process. The initial reset password request looks as shown below (a very typical request with an email field):
Now the following request is where it goes wrong. The application sends another HTTP post request; however, it contains some juicy information. The following screenshot – contains four of parameters that an attacker could modify that include: fromAddress, toAddress, subject, and htmlBody. Manipulating these fields could allow an attacker to potentially send phishing emails to anybody they want. To keep with the subject of this blog post – we can identify in the htmlbody of the message, the HTTP request contains the password reset link that the user would receive to reset their password.
Up-close screenshot:
Full screenshot:
Outcome
If an attacker knows ANY valid email address utilized within the application, the attacker can change the password to their account by intercepting the HTTP request and navigating to the URL within the htmlBody parameter.
How To Fix
The following recommendation was made to remediate the issue:
“Ensure the password reset functionality messages are performed server side to prevent unauthorized users from obtaining access to the password reset token.”
Refer to the following resource for additional remediation steps:
https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs
