🎯 Objective

Gain unauthorized access to the administrator account and delete the user carlos.

🧠 Vulnerability Overview

The application is vulnerable to Insecure Direct Object Reference (IDOR).

This occurs when:

• The application uses user-controlled input (id parameter)
• There is no proper authorization check
• Users can access other users' data by modifying request parameters

🔍 Reconnaissance

After logging in with the provided credentials:

GET /my-account?id=wiener HTTP/1.1The application returns account details for the logged-in user.

👉 Observation:

• The id parameter directly references the username
• No validation is performed to confirm ownership

⚔️ Exploitation Steps

1️⃣ Login as normal user

Use supplied credentials:

username: wiener
password: peter

2⃣ Access account page

Navigate to:

/my-account?id=wiener

3️⃣ Intercept request using Burp Suite

• Turn Intercept ON
• Capture the request

• Send to Repeater

4️⃣ Modify the id parameter

Change:

GET /my-account?id=wiener

To:

GET /my-account?id=administrator

5️⃣ Analyze the response

The server responds with:

username: administrator
password: eeun327dee7ixb1x1g2o

💥 Sensitive information disclosure confirmed.

6️⃣ Login as administrator

Use extracted credentials:

username: administrator
password:eeun327dee7ixb1x1g2o

7️⃣ Delete user "carlos"

• Navigate to admin panel

• Locate user: carlos
• Delete the user

✅ Lab completed successfully 🎉

⚠️ Impact

This vulnerability allows:

• Unauthorized access to other users' accounts
• Exposure of sensitive data (passwords)
• Full account takeover (including admin)

🛡️ Mitigation

To prevent IDOR vulnerabilities:

• ✅ Implement server-side authorization checks
• ✅ Ensure users can only access their own data
• ✅ Avoid exposing direct object references (use indirect IDs)
• ✅ Validate session ownership before returning data

🧩 Key Takeaway

Never trust user-controlled input for access control decisions.

🔥 Good job — this is so classic IDOR,

very common in bug bounty.