Authentication Vulnerabilities: Lab 10: Password reset broken logic

Nov 10, 2025    #websecurity   #portswigger   #web-exploitation   #security-research   #authentication   #login   #username-enumeration   #response-timing   #portswigger-labs   #xss   #ctf-writeup   #password-reset-poisoning  

Lab 10: Password reset broken logic:

This lab’s password reset functionality is vulnerable. To solve the lab, reset Carlos’s password then log in and access his “My account” page.

Your credentials: wiener:peter Victim’s username: carlos

Initial Reconnaissance/Discovery:

We have access to a web application with a “My account” section as well as an email client.

Examining The Password Reset Process:

As we know the password reset process is vulnerable, let’s go through this process to see how it work & look for where we can exploit it.

Let’s navigate to the “My account” page where we can see the “Forgot password?” option.

We are prompted for our username or email, we can enter the provided email client’s email.

Once we hit submit we are told to check our email for the link.

Checking our email we are provided the link.

Looking at the page we are taken to we have a standard option of providing a new password & looking at the string value it does appear to randomly generated.

Let’s put in a new password & copy the url.

If we try and revisit the link again once submitted we can see the token is no longer valid and has been revoked. This is good from a security point of view as these tokens should be revoked once used.

Examining the password reset POST request in burp we can see the username wiener is part of the request.

Let’s initiate another reset but intercept the requests and modify the username to be “carlos” to see if that works.

Performing A Password Reset On Behalf Of Our Target User:

First we initiate another password reset & click the link in the email client.

We turn intercept on in burp suite.

We then enter the password we want to use & submit the request.

We can then modify the username that the password is being reset for to be carlos & forward the request on.

If we try and login as “carlos” we can see it works and we solve the lab.

Why This Is Vulnerable:

When the token is issued it should have a mechanism that ensures that only the correct (user who initiated the request) user’s password can be changed and then the token should be destroyed/invalidated. We can see from our testing the token is invalid once a reset has taken place as checking the endpoint forgot-password?temp-forgot-password-token=[token] once a token is used will not work, however by intercepting the POST request we can change any users password.



Next: Authentication Vulnerabilities: Lab 11: Password reset poisoning via middleware