PortSwigger Walkthrough - Password reset broken logic
Walkthrough of PortSwigger's 'Password reset broken logic' lab.
To browse all labs in this series, visit the full PortSwigger series.
All testing shown in this series is performed against PortSwigger Academy’s intentionally vulnerable labs.
Do not apply these techniques to systems you do not own or have explicit written permission to test.
What’s this?
Password reset flows are full of logic flaws, and this is one of the most straightforward ones. The reset token proves you received an email to a specific address. What it should not do is let you decide which account to reset. If the username is a separate, client-supplied parameter in the reset request, you can use your own valid token to reset anyone else’s password. The token and the account are not bound to each other server-side.
Objective
Reset Carlos’s password without access to his email, then log in and access his account page. Credentials wiener:peter are provided.
Walkthrough
Go to the login page and click Forgot password?. Request a reset for wiener, open the email via the exploit server’s email client, and follow the reset link. Fill in a new password and submit with the proxy active.
Inspect the POST /forgot-password request. The body will look like:
1
temp-forgot-password-token=TOKEN&username=wiener&new-password-1=newpass&new-password-2=newpass
There it is: username=wiener as a plain POST parameter. The server is trusting the client to specify which account is being reset. Send this request to Repeater, change username=wiener to username=carlos, set any new password for both fields, and send.
The server resets Carlos’s password. Log in as carlos with the new password we set and the lab is done.
