Insecure Direct Object Reference (IDOR) — TryHackMe IDOR Room

1. Overview

In this report, I document the discovery of an Insecure Direct Object Reference (IDOR) vulnerability within the web application provided in the TryHackMe IDOR room. This vulnerability allows an attacker to access unauthorized data by manipulating object identifiers in background API requests.

2. Vulnerability Details

• Vulnerability Name: Insecure Direct Object Reference (IDOR) / Broken Access Control
• Severity: High
• Endpoint: /api/v1/customer
• Parameter: id

3. Proof of Concept (PoC)

Steps taken to identify and exploit the vulnerability:

1. Reconnaissance: After logging into the application, I monitored network traffic using Burp Suite to understand how the application handles data requests.
2. Intercepting Traffic: I observed a background API request triggered to fetch account details:

GET /api/v1/customer?id=50 HTTP/1.1
Host: 10-113-186-48.reverse-proxy.cell-prod-eu-central-1b.vm.tryhackme.com
Cookie: session=4a25fdf2e313812256fab2069a6223f3

GET /api/v1/customer?id=50 HTTP/1.1
Host: 10-113-186-48.reverse-proxy.cell-prod-eu-central-1b.vm.tryhackme.com
Cookie: session=4a25fdf2e313812256fab2069a6223f3

• The server response: {"id":50, "username":"kero", "email":"kero@gmail.com"}

• Exploitation: I sent this request to Burp Repeater and modified the id parameter from 50 to 1.

GET /api/v1/customer?id=1 HTTP/1.1

GET /api/v1/customer?id=1 HTTP/1.1

1. Result: The server successfully returned the profile information for the user with id=1 (adam84), confirming that the application fails to verify if the authenticated user has permission to access this resource. Modified server response: {"id":1, "username":"adam84", "email":"adam-84@fakemail.thm"}

4. Remediation

To fix this vulnerability, the following measures must be implemented:

• Server-Side Authorization: The application must never rely solely on user-supplied input to fetch data. The server must verify that the session owner has explicit permission (ownership) to access the requested resource ID before returning any data.
• Indirect References: While using UUIDs makes IDs unguessable, they are not a substitute for proper authorization. Always combine non-predictable IDs with strict server-side access control checks.

#CyberSecurity #PenetrationTesting #InfoSec #WebSecurity #BugBounty #IDOR #BrokenAccessControl #OWASP #VulnerabilityAssessment #LearningJourney #PracticalCyberSecurity #TryHackMe #SecOps #EntryLevelCyberSecurity