Password Reset Bypass Testing

A comprehensive skill for security researchers and penetration testers to identify and test password reset vulnerabilities in web applications.

When to Use This Skill

Use this skill when:

• Testing password reset functionality for security vulnerabilities
• Auditing authentication and account recovery flows
• Assessing reset token generation and validation mechanisms
• Evaluating password change endpoints for bypass vulnerabilities
• Reviewing session management during password reset operations
• Testing for account takeover via password reset mechanisms

Testing Methodology

1. Password Reset Token Leak Via Referrer

What to test: Check if password reset tokens leak through HTTP Referer headers when users navigate to third-party sites.

Testing steps:

1. Request a password reset to your test email address
2. Click the reset link provided in the email
3. Do not change your password yet
4. Navigate to a third-party website (e.g., example.com) while intercepting requests with Burp Suite
5. Inspect the Referer header to see if it contains the password reset token

What to look for:

• Token in URL query parameters (e.g.,

  ?token=abc123

  )
• Token in URL path segments
• Any sensitive data in the Referer header

Impact: Account takeover via CSRF attacks if third parties can capture the token.

2. Password Reset Poisoning

What to test: Check if the application uses the Host header to construct password reset URLs.

Testing steps:

1. Intercept the password reset request
2. Modify the Host header to point to your controlled domain
3. Submit the request and check the reset email
4. Verify if the reset link points to your malicious domain

Example:

POST /resetPassword HTTP/1.1
Host: attacker.com
Content-Type: application/x-www-form-urlencoded

email=victim@example.com

What to look for:

• Reset links pointing to attacker-controlled domains
• Use of

  $_SERVER['HTTP_HOST']

  instead of

  $_SERVER['SERVER_NAME']

Mitigation: Validate Host header against whitelist, use server-side URL generation.

3. Email Parameter Manipulation

What to test: Check if additional email parameters can divert reset links to attacker emails.

Testing variations:

email=victim@email.com&email=attacker@email.com

email=victim@email.com%20email=attacker@email.com

email="victim@mail.tld%0a%0dcc:attacker@mail.tld"

email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"

email="victim@mail.tld",email="attacker@mail.tld"

{"email":["victim@mail.tld","attacker@mail.tld"]}

What to look for:

• Multiple reset emails sent
• Reset link sent to attacker email
• Application processing all email parameters

4. API Parameter Manipulation

What to test: Check if email/password parameters in API requests can be modified to change account credentials.

Testing steps:

1. Intercept password change API requests
2. Modify the email parameter to target a different account
3. Submit the request and verify if the password was changed

Example:

POST /api/changepass
Content-Type: application/json

{"form": {"email":"victim@email.tld","password":"12345678"}}

What to look for:

• Password changed for different user than authenticated user
• Missing ownership verification

5. Rate Limiting Assessment

What to test: Check for lack of rate limiting on password reset requests.

Testing steps:

1. Send multiple password reset requests in quick succession
2. Monitor for email bombing (user receiving many reset emails)
3. Check for account lockout or CAPTCHA challenges

What to look for:

• No rate limiting based on IP or account
• No CAPTCHA after multiple attempts
• Ability to spam users with reset emails

6. Token Generation Analysis

What to test: Understand how password reset tokens are generated to assess predictability.

Common patterns to check:

• Based on timestamp
• Based on UserID
• Based on email address
• Based on user attributes (name, DOB)
• Based on weak cryptography

Testing tools:

• Use Burp Sequencer to analyze token randomness
• Use guidtool for UUID analysis

What to look for:

• Predictable patterns in tokens
• Version 1 UUIDs (time-based, potentially guessable)
• Short token length (< 128 bits)
• Low entropy in token generation

7. Token Expiration Testing

What to test: Check if expired tokens can still be used for password reset.

Testing steps:

1. Request a password reset and obtain a valid token
2. Wait for the token to expire (check documentation or test various timeframes)
3. Attempt to use the expired token

What to look for:

• Expired tokens still accepted
• No server-side expiration validation
• Inconsistent expiration enforcement

8. Brute Force Token Testing

What to test: Check if reset tokens can be brute-forced.

Testing steps:

1. Analyze token format and length
2. Use tools like Burp Suite with IP rotator to bypass rate limits
3. Attempt to guess valid tokens

What to look for:

• Short token length
• Predictable token format
• No rate limiting on token validation
• No account lockout after failed attempts

9. Token Cross-User Testing

What to test: Check if an attacker's reset token can be used with a victim's email.

Testing steps:

1. Request password reset for attacker's account
2. Obtain the reset token
3. Attempt to use attacker's token with victim's email address

What to look for:

• Token not bound to specific user
• Token validation only checks format, not ownership

10. Session Invalidation Testing

What to test: Check if sessions are properly invalidated after password reset.

Testing steps:

1. Log in to a test account
2. Request and complete a password reset
3. Check if the original session remains valid
4. Verify if all sessions are invalidated

What to look for:

• Old sessions remain active after password change
• No session invalidation on logout
• Session tokens not rotated after password reset

11. OTP Rate Limit Bypass

What to test: Check if OTP rate limits can be bypassed by changing sessions.

Testing steps:

1. Request password reset with OTP
2. Attempt multiple wrong OTP guesses until rate limited
3. Request a new session token
4. Continue guessing with new session

What to look for:

• Rate limiting based only on session, not IP/account
• Weak OTP (≤ 4 digits)
• No persistent rate limiting across sessions

12. skipOldPwdCheck Vulnerability

What to test: Check for password change endpoints that skip old password verification.

Testing steps:

1. Look for password change endpoints with action parameters
2. Test if

   skipOldPwdCheck=true

   or similar parameters can be added
3. Attempt to change password without providing old password or reset token

Example vulnerable pattern:

POST /hub/rpwd.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded

action=change_password&user_name=admin&confirm_new_password=NewP@ssw0rd!

What to look for:

• Password change without authentication
• Missing token verification
• skipOldPwdCheck or similar bypass parameters

13. Registration-as-Password-Reset (Upsert)

What to test: Check if registration endpoint updates existing users instead of rejecting.

Testing steps:

1. Attempt to register with an existing email address
2. Provide a new password in the registration request
3. Check if the existing user's password was updated

Example:

POST /api/register
Content-Type: application/json

{"email":"victim@example.com","password":"New@12345"}

What to look for:

• Registration succeeds with existing email
• Existing user's password is overwritten
• No duplicate email validation

Reporting Findings

When documenting vulnerabilities, include:

1. Vulnerability type (e.g., "Password Reset Token Leak via Referrer")
2. Affected endpoint (URL and HTTP method)
3. Request/Response examples showing the vulnerability
4. Impact assessment (e.g., "Full account takeover possible")
5. Mitigation recommendations
6. References to similar vulnerabilities or CVEs

Mitigation Guidelines

General Recommendations

• Use strong, cryptographic token generation (≥ 128 bits of entropy)
• Implement server-side token validation with expiration
• Bind tokens to user sessions and IP addresses
• Implement rate limiting on reset requests and token validation
• Invalidate all sessions after password change
• Use HTTPS for all authentication-related endpoints
• Implement proper input validation and output encoding

Specific Mitigations

$_SERVER['SERVER_NAME']

References

• HackerOne Report 342693
• HackerOne Report 272379
• Acunetix - Password Reset Poisoning
• OWASP Authentication Cheat Sheet
• OWASP Password Storage Cheat Sheet

Test Cases

Use these test prompts to validate the skill:

1. "Test the password reset functionality at https://example.com/reset for token leakage via referrer header"
2. "Check if the password reset endpoint at /api/resetPassword is vulnerable to email parameter manipulation"
3. "Assess the password reset token generation for predictability and brute-force resistance"
4. "Verify if sessions are properly invalidated after password reset on the application"
5. "Test for registration-as-password-reset vulnerability on the signup endpoint"