PortSwigger Lab: User ID controlled by request parameter with password disclosure

Lab Information:

Vulnerability Location: User ID controlled by request parameter + Password disclosure
Difficulty: Apprentice
Objective: Log in to the administrator account and delete the user carlos.
Tools: Burp Suite, Burp Repeater
Provided Credentials: wiener:peter

Understanding the Vulnerability

This lab combines two vulnerabilities:

Insecure Direct Object Reference (IDOR): The application uses the id parameter to identify user accounts. Because there is no server-side authorization check, any authenticated user can access another user's account simply by changing this parameter.
Password Disclosure: The application exposes the current password in plain text inside the HTML source code of the account page. This allows an attacker who gains access to any account to immediately obtain that user's password.

Reconnaissance:

With Burp Suite running, I navigated to the /my-account page and logged in using the credentials provided by the lab (wiener:peter).

After logging in, I was redirected to:

GET /my-account?id=wiener HTTP/2

GET /my-account?id=wiener HTTP/2

The id parameter directly contains the username. While inspecting the page source, I noticed that the password field was populated with the current password in plain text:

<input required type="password" name="password" value="peter"/>

<input required type="password" name="password" value="peter"/>

This immediately revealed two issues: the ability to change the id parameter and the exposure of the password in the HTML.

Exploitation:

Step 1: Access the administrator account via IDOR

I sent the request to Burp Repeater and changed the id parameter from wiener to administrator:

GET /my-account?id=administrator HTTP/2

GET /my-account?id=administrator HTTP/2

The application returned the administrator's account page without any authorization check.

Step 2: Extract the administrator password

While on the administrator account page, I inspected the HTML source and found the administrator's current password exposed in plain text:

<input required type="password" name="password" value="wmva0475hq55k8ayvpr6"/>

<input required type="password" name="password" value="wmva0475hq55k8ayvpr6"/>

Step 3: Log in as administrator and delete Carlos

I logged out of the wiener account and logged in as administrator using the password obtained (wmva0475hq55k8ayvpr6).

Once logged in as an administrator, I accessed the admin panel and deleted the user Carlos, completing the lab objective.

Impact

This vulnerability has a high impact because it allows an attacker to:

Access any user account by simply changing the id parameter (IDOR);
Obtain the password of any user in plain text, including the administrator;
Escalate privileges to administrator level;
Perform destructive actions such as deleting user accounts.

In a real-world scenario, this could lead to full account takeover of high-privilege users and complete compromise of the application.

Remediation

To fix this vulnerability, the application should:

Implement proper server-side authorization checks to ensure that the authenticated user is only allowed to access their own account (or accounts they are explicitly authorized to manage);
Never expose sensitive information such as passwords in the HTML source code. The password field should not be pre-filled with the actual password value;
Use secure password handling practices (e.g., never return the current password to the client);
Apply the principle of least privilege and enforce strict access control on all user-related endpoints.

Disclaimer

This write-up was created for educational purposes only. All testing was performed in an authorized PortSwigger Web Security Academy laboratory environment. Never test systems without explicit authorization.

Contents