PortSwigger Lab Write-Up: Insecure Direct Object References

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.

For today's session, I'm going to solve a lab under Access Control Vulnerabilities category named "Insecure Direct Object References". This lab stores user chat logs directly on the server's file system, and retrieves them using static URLs. Solve the lab by finding the password for the user 'Carlos', and logging into their account. For this, there is no credential given like the others. So we need to find the password that hidden somewhere.

Lab: Insecure direct object references This lab stores user chat logs directly on the server's file system, and retrieves them using static URLs. Solve the…

Lets get into it!

I accessed the lab and tried to find a way to interact with the support feature, which was to use the Live Chat option.

I clicked on Live chat to open the chat window.

I sent a random message just to trigger the chat to generate a transcript.

Then I clicked 'View transcript', which downloaded a text file. I also checked the URL and noticed it pointed to a numbered file like '/download-transcript/2.txt'.

I changed the number in the URL so it would download 1.txt instead. So, I modified the URL by adding '/download-transcript/2.txt' at the end.

After the file downloaded, I opened that 1.txt file and read through its contents, and noticed there was a password sitting inside the conversation.

I went back to the login page and signed in using the username 'carlos' along with the password I just found.

After logging in successfully, the lab now marked as Solved!

This lab shows why sequential, guessable file names are risky when they point to sensitive data. The server just trusted whatever number was in the URL, without ever checking if that transcript actually belonged to the person requesting it. To avoid this, resources shouldn't be exposed through predictable identifiers in the first place, and the server should always verify ownership before handing anything over. Above all of that, sensitive info like passwords shouldn't end up written in plaintext chat logs to begin with.

That's all for this lab, thanks!