Introduction

This report presents the analysis and exploitation of a time‑sensitive vulnerability identified in a web application's password reset functionality during testing on the PortSwigger Web Security Academy lab titled Exploiting time-sensitive vulnerabilities. The objective of the assessment was to investigate weaknesses in the password reset mechanism that could allow an attacker to gain unauthorized access to another user's account.

Password reset features are critical security components because they allow users to regain access to their accounts. If these mechanisms are improperly implemented, attackers may exploit them to bypass authentication controls and take over user accounts. In this lab scenario, the application generates password reset tokens in a predictable way that depends on time-based values rather than using cryptographically secure randomness.

Through careful observation of the password reset process and the use of parallel HTTP requests in Burp Suite, it is possible to trigger the generation of identical reset tokens for different users. By exploiting this behavior, an attacker can obtain a valid password reset token for another user, reset their password, and gain access to their account.

The goal of this report is to document the methodology used to identify the vulnerability, explain the exploitation process, and demonstrate how the weakness leads to account takeover. Additionally, the report highlights the security implications of predictable token generation and emphasizes the importance of implementing secure cryptographic practices when designing authentication and password recovery mechanisms.

1 .LAB OVERVIEW

This lab demonstrates how a password reset mechanism can become vulnerable when reset tokens are generated using predictable, time‑based values. The objective is to obtain a valid password reset token for another user (carlos) and take over the account.

2. Understanding the Password Reset Mechanism

The application provides a Forgot Password feature where a user submits their username to receive a password reset link via email. The reset link contains two parameters:

None
  • after login logout again in order to create session then click forget password and enter username "wiener" then submit and go to the submit link
None

as you see into submit link then click link and reset the new password

None
None

after that go to the burp proxy >> proxyhistory and capture the GET and POST request and then send to repeater

None
  • user
  • token
None

The token is used by the server to verify that the password reset request is valid.

before create another request from POST duplicate and then create group for two POST request

None

3. Identifying the Vulnerability

After sending multiple password reset requests, it can be observed that each request generates a different token. However, analysis suggests that the token generation relies on a timestamp‑based value rather than a secure random generator.

choose two send in parallel

None

go into GET and delete sessionPHP then send the request again

None

action after delete the session and send the request we see we get a new phpsessionid and csrf into response

None

phpsessionid=WYo7uhEbXegpdfyaQ8wlVac87Y9kGxrh

None

then take the value of phpsession and crsf from GET and replace to new POST request of carlos

None

Because of this, if two reset requests are processed at the same moment, the system may generate identical tokens.

4. Exploitation Steps

Using Burp Suite Repeater, two password reset requests are prepared:

  • Request 1 → username=wiener
None
  • Request 2 → username=carlos
None

Since the backend uses PHP session locking, each request must use a different session ID. After assigning separate sessions, both requests are sent in parallel to trigger token generation at the same timestamp.

None

5. Account Takeover

Once the requests are sent simultaneously, the application generates the same reset token for both users. The attacker receives the reset email for wiener, which contains a valid token.

None

By modifying the reset link and replacing the username parameter with carlos, it becomes possible to reset Carlos's password and log into the account.

None
Enter the password you want
None

to solve the lab go the admin panel and then delete one user

None

as you see

None

DONE!!

None

6.CONCLUSION

This lab highlights the risk of generating security tokens using predictable values such as timestamps. Applications should always use cryptographically secure random generators when creating password reset tokens to prevent attackers from predicting or reproducing them.

ALL THE BEST!!!!!!