Introduction
Modern web applications need to prioritize user security. However, even well-designed systems can have hidden flaws that make them vulnerable to attacks. During a recent security test, a serious issue was found in the password reset feature of an application. This vulnerability made it possible for attackers to gain access to any user account, including the super administrators. Here’s what went wrong and why it’s such a big problem.
The flaw in password reset
The issue came from the way the application managed password reset tokens. Normally, when a user asks to reset their password, the system creates a unique token specifically for that user to complete the reset process. However, in this case, the application worked differently. By tweaking the request that checks the token, it was possible to trick the system into providing a token for a random user instead of the one making the request. This flaw allowed attackers to take full control of accounts, including those with administrative privileges.
Exploitation time
The exploitation process was simple and could be replicated with minimal effort:
1. Obtaining Session Identifiers: First, the attacker navigated to the application and acquired the session cookie (PHPSESSID) and the X-Xsrf-Token header. These identifiers are necessary for sending authenticated requests.
2. Sending a Malicious Request: A crafted POST request was sent to the application’s token verification endpoint. Instead of providing a legitimate token value, the payload contained the parameter “token”:{"":null}. This unexpected input triggered the server to respond with a token belonging to a random user.
This unexpected input triggered the server to respond with a token belonging to a random user:
3. Extracting Tokens: Each time the malicious request was sent, the server returned a different token. Using these tokens, the attacker could reset the passwords of multiple users, gaining access to their accounts.
4. Taking Over Accounts: With a valid token, the attacker navigated to the reset password URL, entered a new password, and confirmed the action. This granted them full access to the compromised account.
The scope
This vulnerability had serious impact:
Lack of user notification: Users were not alerted when a password reset token was generated or used. As a result, a victim remained unaware that their account had been compromised until they attempted to log in and found their password invalid.
Comprehensive access: Tokens could be acquired for any user in the application. This included newly registered accounts, as the system pre-generated tokens during registration. Even accounts that had recently reset their passwords were vulnerable because tokens were stored in the database indefinitely.
A flawed token management system: The application’s approach to token generation was fundamentally insecure. Tokens were created in advance and stored until needed, rather than being generated dynamically when a user initiated a password reset.
What went wrong?
This vulnerability happened because the application didn’t handle password reset tokens properly. Instead of creating tokens only when someone asked to reset their password, the app generated and stored them in advance, which made it easier for attackers to exploit. On top of that, users weren’t notified when their password reset tokens were used, so attackers could take over accounts without anyone noticing.
The Fix
To address this issue, developers should revise how the application handles password reset requests. According to best practices outlined by OWASP, password reset tokens should:
- Be generated dynamically and only when a reset request is made for a specific user or email address.
- Be associated with a short expiration period to limit their lifespan.
- Trigger user notifications whenever a reset is initiated, providing an additional layer of security.
These steps would ensure that tokens are both secure and limited in scope, reducing the risk of unauthorized account access.
Lessons for SDLC
This case serves as a reminder that even routine functionality like password resets can become a significant security liability if not implemented correctly. Developers must adopt secure coding practices and test their applications for vulnerabilities.
