Testing Password Reset Vulnerabilities

Hello! In our last lesson, we dug into session fixation, where an attacker can hijack a user's session by forcing them to authenticate into a session the attacker already controls. We saw how this stems from the application's failure to create a new session ID upon login.

Today, we'll shift our focus to another critical authentication workflow that is a prime target for attackers: the password reset process. This lesson directly addresses the learning outcome: Test password reset workflows for logic flaws, such as token leakage or parameter tampering, to achieve account takeover.

A flawed password reset mechanism can completely undermine an application's security, allowing an attacker to walk right through the front door. We will explore two primary ways this happens:

1. Token Leakage via Parameter Tampering: Tricking the application into sending a legitimate password reset token to an attacker.
2. Predictable Tokens: Exploiting weak token generation logic to guess or deduce a victim's reset token.

Let's begin by understanding what can go wrong.

1. The Anatomy of a Password Reset Flaw

A secure password reset process is designed to ensure only the legitimate owner of an account can reset its password. This typically involves generating a unique, high-entropy, single-use, and short-lived token that is sent to the user's registered email address.

Vulnerabilities appear when any part of this process is mishandled. An attacker's goal is to either intercept the token intended for the victim or to predict the token before the victim can use it. Today, we'll focus on the logic flaws that make this possible.

2. Attack Vector 1: Leaking the Token via Parameter Tampering

This class of attack involves manipulating parts of the HTTP request to trick the server's back-end logic. The server generates a perfectly valid token but is deceived about where to send it or how to construct the link containing it.

Host Header Poisoning

One of the most common ways to achieve this is through Host Header Poisoning. Many web applications use the Host header from the incoming HTTP request to construct absolute URLs, including password reset links sent in emails. If the application doesn't validate this header, an attacker can substitute their own domain.

The attack flow is simple:

1. The attacker requests a password reset for the victim's account.
2. They intercept this request using a proxy like Burp Suite.
3. They modify the Host header to point to a server they control (e.g., attacker.com).
4. The application receives the request, generates the reset token, and constructs the reset link using the malicious Host header: http://attacker.com/reset?token=....
5. This email is sent to the victim's email address, but the link points to the attacker's server. If the victim clicks it, their browser sends the valid reset token directly to the attacker.

A more direct variation is when the application uses the Host header not just for the link, but to determine which email server to talk to. By changing it, the reset email itself can be routed to an attacker's mail server.

This video provides a great hands-on demonstration of this attack.

This vulnerability often arises because developers assume the Host header is a reliable piece of information, but like any user-supplied input, it must be validated. For a more detailed textual explanation and examples of the HTTP requests involved, you can refer to the "Host Header Poisoning" section of the VaaData article on password reset vulnerabilities.

Tampering with Other Parameters

The Host header is not the only user-controllable parameter that can be abused. Some applications explicitly use a parameter in the request body (e.g., in a JSON object) to construct the base URL for the reset link.

This is a design flaw, but it happens. For a practical look at this, let's explore an article that details a real-world exploit.

As you can see from this example, even when developers attempt to validate user input, clever manipulation can bypass weak checks. Your computer science background will help you appreciate how different parsers and libraries can interpret the same string in different ways, leading to security flaws.

3. Attack Vector 2: Predicting the Token

What if you can't trick the application into sending you the token? The next best thing is to predict it. This becomes possible if the token is not generated with sufficient randomness (entropy). A common anti-pattern is using predictable values, like the server's timestamp, as a primary source for token generation.

If two password reset requests are processed at the exact same millisecond, and the token generation algorithm relies on that timestamp, both requests might end up with the exact same token.

This leads to a classic attack:

1. The attacker sends two password reset requests at the same time: one for their own account and one for the victim's account.
2. If the server processes them simultaneously, it generates the same token for both accounts.
3. The attacker receives the reset link for their own account via email.
4. They take the token from their own link and use it to reset the password for the victim's account.

The following video gives a quick and clear overview of this concept.

Hands-On: Exploiting a Time-Sensitive Vulnerability

Now, let's look at how to execute this in a real-world scenario using Burp Suite. PortSwigger, the creators of Burp, have a lab specifically for this type of time-sensitive vulnerability. While you won't be doing the lab interactively right now, understanding the solution steps is crucial.

The key takeaway from this lab is the methodology: you must ensure your requests are being processed concurrently, not sequentially. Bypassing session-based locking by using different session cookies for each request is a vital technique for testing this and other race condition vulnerabilities.

Conclusion

Password reset functionality is a gateway to a user's account, and as we've seen, it can have many implementation flaws. A successful attack here almost always leads to a critical-impact finding.

Key Takeaways:

• Always Test the Reset Workflow: It's a high-value target for bug bounties and penetration tests.
• Tamper with Everything: Scrutinize every part of the password reset request that you control. This includes the Host header and any parameters in the URL, body, or other headers that could influence how the reset link is generated.
• Race for the Token: Test for predictability. Use Burp Suite's parallel request features (like in Repeater tab groups) to send simultaneous requests for your account and a target's account to see if you can force a token collision. Remember to use different session cookies to bypass sequential processing.
• The Goal is the Token: Whether you leak it or predict it, getting your hands on a valid reset token for another user's account is the objective.

Next Lesson Preview:
We've now covered flaws in session management and password resets. What happens when an application adds another layer of security? In our next lesson, we will begin to answer that by learning how to identify and exploit insecure multi-factor authentication (MFA) implementations for bypass.