Solving PortSwigger Lab: Password Brute-Force via Password Change

Welcome to this step-by-step walkthrough for the "Password brute-force via password change" lab from PortSwigger's Web Security Academy. In authentication security, brute-force defenses often focus heavily on primary endpoints such as /login. However, auxiliary features—such as user registration, password resets, and password update forms—frequently expose identical authentication logic without the same rate-limiting or lockout mechanisms.

Note: This article was written with the assistance of AI tools.

1. Vulnerability Analysis & Core Logic

The Flaw

When a web application allows logged-in users to change their password, it usually requires entering the current password as a security measure to prevent unauthorized changes via CSRF or open sessions.

The security vulnerability in this lab stems from two key implementation flaws:

1. Broken Access Control in Password Reset Logic: The password change request explicitly includes a hidden or editable username parameter (username=wiener). If the backend processes password changes for whichever username is supplied in the request body without checking if it matches the active session cookie, an attacker can attempt to change any arbitrary user's password (e.g., target carlos).
2. Differential Response Oracle: When validating password change attempts, the application checks conditions sequentially:

• Condition A: Is the supplied current-password correct for the specified username? If incorrect, it returns:
• <p class="is-warning">Current password is incorrect</p>
• Condition B: Do new-password-1 and new-password-2 match? If the current password is correct, but the new passwords intentionally do not match, it returns:
• <p class="is-warning">New passwords do not match</p>

By intentionally providing mismatching new passwords, we turn the password-change endpoint into a boolean oracle. We can brute-force the target user's current password without actually changing their password or triggering standard lockouts.

2. Reconnaissance & Baseline Probing

Log into the application using the provided credentials (wiener:peter) and navigate to the My Account page. Perform a standard password change request while intercepting traffic using Burp Suite.

Test 1: Supplying an Invalid Current Password

Send the captured POST request to Burp Repeater. Modify current-password to an invalid value (peter).

Test 2: Supplying the Valid Current Password with Mismatched New Passwords

Next, supply the valid current password (peter), but set new-password-1=vq and new-password-2=va.

This differential response confirms our logic:

• Response includes "Current password is incorrect" →Password candidate is FALSE.
• Response includes "New passwords do not match" → Password candidate is TRUE.

3. Configuring Burp Intruder Brute-Force Attack

Now, we pivot our target from wiener to carlos.

1. Send the password change POST request to Burp Intruder.
2. Set the username parameter to carlos.
3. Set intentionally mismatching values for the new password fields (e.g., new-password-1=v and new-password-2=vs).
4. Place a single payload position marker on the current-password parameter:
5. HTTP

POST /my-account/change-password HTTP/2
Host: 0a2e00f803a432e4804399420089007e.web-security-academy.net
Cookie: session=...
...

username=carlos&current-password=§peter§&new-password-1=v&new-password-2=vs

POST /my-account/change-password HTTP/2
Host: 0a2e00f803a432e4804399420089007e.web-security-academy.net
Cookie: session=...
...

username=carlos&current-password=§peter§&new-password-1=v&new-password-2=vs

1. In the Settings tab under Grep — Match, add a match rule for New passwords do not match.

1. Under the Payloads tab, paste the list of candidate passwords provided by the lab.
2. Click Start attack.

4. Execution & Exploit Verification

Monitor the Intruder attack results. Look for the request that flags a match under your Grep — Match column or displays a distinct response length.

As observed in the results:

• Payload yankees evaluated to TRUE for the New passwords do not match rule.
• This identifies yankees as the valid current password for user carlos.

With Carlos's password confirmed, log out of wiener and log in as carlos using password yankees.

5. Remediation Guidelines

To protect application endpoints against password-change brute-forcing and session manipulation:

1. Enforce Strict Session Ownership: Never rely on user-supplied parameters (like username=...) to determine whose account is being modified. Always derive the identity of the account being updated directly from the authenticated server-side session context.
2. Apply Uniform Rate-Limiting: Enforce strict rate-limiting and account lockout policies across all sensitive operations, including login, password reset, and password change endpoints.
3. Prevent Response Oracles: Validate all inputs holistically or handle errors consistently so that invalid field states do not disclose sensitive validation order details to potential attackers.