Web Security Day 4 (Part 2): PortSwigger Writeup — User ID Controlled by Request Parameter with Password Disclosure

Photo by Mika Baumeister on Unsplash

Hello everyone! To wrap up the Access Control chapter of my web security documentation, I am tackling one final PortSwigger lab: User ID controlled by request parameter with password disclosure.

This lab is a fantastic example of how a Horizontal Privilege Escalation vulnerability (IDOR) can quickly chain into a full Vertical Privilege Escalation (Admin Account Takeover) when sensitive data is mishandled on the frontend.

Vulnerability Concept

Many applications include a “My Account” page where users can update their profiles. Often, these pages pre-fill existing data into the form inputs for convenience.

A critical vulnerability occurs when two bad practices combine:

1. The application relies on a user-controllable URL parameter (e.g., ?id=wiener) to fetch profile data without verifying if the active session actually owns that ID.
2. The application pre-fills highly sensitive data, such as passwords, directly into the HTML source code (e.g., <input type="password" value="secret123">).

By changing the ID parameter to a target user, an attacker can load the victim’s profile and simply inspect the page source to extract their password.

Lab Objective

The goal is to exploit the request parameter to retrieve the administrator’s password, log in to the administrator account, and delete the user carlos. We are provided with the credentials: wiener:peter.

Exploitation Steps

1. Identifying the Vulnerable Parameter

First, I logged into the application using the provided credentials (wiener:peter) and navigated to the "My Account" page.

Looking at the URL bar, I noticed the application used a direct request parameter to load my profile:

Get Yudha Pratama’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Plaintext

/my-account?id=wiener

On this page, there is a masked password input field containing my current password.

2. Horizontal Escalation & Password Disclosure

I decided to test if the backend actually validates my session against the requested ID. In the URL bar, I simply changed the parameter from wiener to administrator and hit Enter:

The server accepted the request and loaded the administrator’s account page. To uncover the masked password, I right-clicked the password field and selected Inspect (or viewed the HTTP response in Burp Suite).

Right there in the plain HTML source code, the administrator’s password was exposed in the value attribute of the input tag:

<input required type="password" name="password" value="admin_password_here">

The Administrator password appears (Burpsuite Response)

3. Account Takeover & Vertical Escalation

I copied the exposed administrator password. I logged out of the wiener account and navigated back to the main login page.

Using the username administrator and the stolen password, I successfully logged into the highly privileged account. I accessed the newly visible Admin Panel, deleted the user carlos, and the lab was marked as Solved.

Successfully logged into the administrator account

Delete Carlos

Lab Solved

How to Prevent This Vulnerability

To prevent this dangerous exploit chain, developers must implement the following controls:

• Enforce Strict Authorization: The server must verify that the session token of the requester matches the owner of the requested data before returning any profile information.
• Never Pre-fill Passwords in HTML: Web applications should never return plaintext or hashed passwords back to the client’s browser within the HTML source. If a user wants to change their password, leave the current password field blank and require them to type it in manually for verification.

That concludes the Access Control module! Documenting these labs has drastically improved my understanding of authorization flaws. Stay tuned as I move on to the next vulnerability category in my cybersecurity journey.