PortSwigger Lab Write-Up: User ID Controlled by Request Parameter with Password Disclosure

Category: Access Control Vulnerabilities Difficulty: Apprentice

PortSwigger is basically a company that focused on developing cybersecurity software. They are best known for their main product, Burp Suite, which is used for penetration testing and web application security. PortSwigger also offers a variety of tools for security testing and scanning, and is dedicated to securing the web. Additionally, they have the PortSwigger Academy, a learning platform for security that I will write about here.

In this write up, I'm going to tackled a lab from Access Control Vulnerabilities category which called 'User ID Controlled by Request Parameter with Password Disclosure'. This lab has a user account page that contains the current user's existing password, prefilled in a masked input. To solve the lab, retrieve the administrator's password, then use it to delete the user 'Carlos'.

Lab: User ID controlled by request parameter with password disclosure This lab has user account page that contains the current user's existing password, prefilled in a masked input. To…

Let started it!

In this lab, I used Burp Suite and a browser with the Burp proxy configured. First, I opened Burp Suite and made sure the intercept was on. Then, I set the browser to route traffic through Burp with Host: 127.0.0.1 and Port: 8080.

First of all, I logged in to the lab using the given credentials, wiener:peter. After logging in, I noticed the URL on my account page had an "id" parameter set to wiener.

I switched to Burp Suite, went to HTTP History, found the request for that account page, right-clicked it, and selected Send to Repeater.

In the Repeater tab, I checked the request and confirmed the id parameter was indeed set to wiener.

I changed the value from 'wiener' to 'administrator' in the id parameter.

Then I clicked Send and scrolled down on the response panel on the right to look for the administrator's password.

I copied that password and tried logging in with it using the administrator username.

After successfully logging in as administrator, I went to the admin panel tab and looked for the user 'carlos' to delete.

Once Carlos was deleted, the lab was marked as Solved!

This lab combines two problems at once: an IDOR vulnerability that lets you view another user's account page, and a password field that's only masked visually but still sends the real value in the HTML. Together, that's enough for a low-privilege user to fully take over the admin account. The lesson I got here is that masking is just a UI trick, not actual security, since the raw password is still there if you check the response. Password fields shouldn't be pre-filled with real values at all, even if they're hidden on screen. And just like before, the server needs to properly verify that users only access their own account data.

That's all for this write up. Thanks for reading!