mirror of
https://github.com/usestrix/strix.git
synced 2026-08-16 01:16:40 +02:00
165 lines
4.2 KiB
Django/Jinja
165 lines
4.2 KiB
Django/Jinja
<idor_vulnerability_guide>
|
|
<title>INSECURE DIRECT OBJECT REFERENCE (IDOR) - ELITE TECHNIQUES</title>
|
|
|
|
<critical>IDORs are among the HIGHEST IMPACT vulnerabilities - direct unauthorized data access and account takeover.</critical>
|
|
|
|
<discovery_techniques>
|
|
<parameter_analysis>
|
|
- Numeric IDs: user_id=123, account=456
|
|
- UUID/GUID patterns: id=550e8400-e29b-41d4-a716-446655440000
|
|
- Encoded IDs: Base64, hex, custom encoding
|
|
- Composite IDs: user-org-123-456, ACCT:2024:00123
|
|
- Hash-based IDs: Check if predictable (MD5 of sequential numbers)
|
|
- Object references in: URLs, POST bodies, headers, cookies, JWT tokens
|
|
</parameter_analysis>
|
|
|
|
<advanced_enumeration>
|
|
- Boundary values: 0, -1, null, empty string, max int
|
|
- Different formats: {"id":123} vs {"id":"123"}
|
|
- ID patterns: increment, decrement, similar patterns
|
|
- Wildcard testing: *, %, _, all
|
|
- Array notation: id[]=123&id[]=456
|
|
</advanced_enumeration>
|
|
</discovery_techniques>
|
|
|
|
<high_value_targets>
|
|
- User profiles and PII
|
|
- Financial records/transactions
|
|
- Private messages/communications
|
|
- Medical records
|
|
- API keys/secrets
|
|
- Internal documents
|
|
- Admin functions
|
|
- Export endpoints
|
|
- Backup files
|
|
- Debug information
|
|
</high_value_targets>
|
|
|
|
<exploitation_techniques>
|
|
<direct_access>
|
|
Simple increment/decrement:
|
|
/api/user/123 → /api/user/124
|
|
/download?file=report_2024_01.pdf → report_2024_02.pdf
|
|
</direct_access>
|
|
|
|
<mass_enumeration>
|
|
Automate ID ranges:
|
|
for i in range(1, 10000):
|
|
/api/user/{i}/data
|
|
</mass_enumeration>
|
|
|
|
<type_confusion>
|
|
- String where int expected: "123" vs 123
|
|
- Array where single value expected: [123] vs 123
|
|
- Object injection: {"id": {"$ne": null}}
|
|
</type_confusion>
|
|
</exploitation_techniques>
|
|
|
|
<advanced_techniques>
|
|
<uuid_prediction>
|
|
- Time-based UUIDs (version 1): predictable timestamps
|
|
- Weak randomness in version 4
|
|
- Sequential UUID generation
|
|
</uuid_prediction>
|
|
|
|
<blind_idor>
|
|
- Side channel: response time, size differences
|
|
- Error message variations
|
|
- Boolean-based: exists vs not exists
|
|
</blind_idor>
|
|
|
|
<secondary_idor>
|
|
First get list of IDs, then access:
|
|
/api/users → [123, 456, 789]
|
|
/api/user/789/private-data
|
|
</secondary_idor>
|
|
</advanced_techniques>
|
|
|
|
<bypass_techniques>
|
|
<parameter_pollution>
|
|
?id=123&id=456 (takes last or first?)
|
|
?user_id=victim&user_id=attacker
|
|
</parameter_pollution>
|
|
|
|
<encoding_tricks>
|
|
- URL encode: %31%32%33
|
|
- Double encoding: %25%33%31
|
|
- Unicode: \u0031\u0032\u0033
|
|
</encoding_tricks>
|
|
|
|
<case_variation>
|
|
userId vs userid vs USERID vs UserId
|
|
</case_variation>
|
|
|
|
<format_switching>
|
|
/api/user.json?id=123
|
|
/api/user.xml?id=123
|
|
/api/user/123.json vs /api/user/123
|
|
</format_switching>
|
|
</bypass_techniques>
|
|
|
|
<special_contexts>
|
|
<graphql_idor>
|
|
Query batching and alias abuse:
|
|
query { u1: user(id: 123) { data } u2: user(id: 456) { data } }
|
|
</graphql_idor>
|
|
|
|
<websocket_idor>
|
|
Subscribe to other users' channels:
|
|
{"subscribe": "user_456_notifications"}
|
|
</websocket_idor>
|
|
|
|
<file_path_idor>
|
|
../../../other_user/private.pdf
|
|
/files/user_123/../../user_456/data.csv
|
|
</file_path_idor>
|
|
</special_contexts>
|
|
|
|
<chaining_attacks>
|
|
- IDOR + XSS: Access and weaponize other users' data
|
|
- IDOR + CSRF: Force actions on discovered objects
|
|
- IDOR + SQLi: Extract all IDs then access
|
|
</chaining_attacks>
|
|
|
|
<validation>
|
|
To confirm IDOR:
|
|
1. Access data/function without authorization
|
|
2. Demonstrate data belongs to another user
|
|
3. Show consistent access pattern
|
|
4. Prove it's not intended functionality
|
|
5. Document security impact
|
|
</validation>
|
|
|
|
<false_positives>
|
|
NOT IDOR if:
|
|
- Public data by design
|
|
- Proper authorization checks
|
|
- Only affects own resources
|
|
- Rate limiting prevents exploitation
|
|
- Data is sanitized/limited
|
|
</false_positives>
|
|
|
|
<impact>
|
|
- Personal data exposure
|
|
- Financial information theft
|
|
- Account takeover
|
|
- Business data leak
|
|
- Compliance violations (GDPR, HIPAA)
|
|
</impact>
|
|
|
|
<pro_tips>
|
|
1. Test all ID parameters systematically
|
|
2. Look for patterns in IDs
|
|
3. Check export/download functions
|
|
4. Test different HTTP methods
|
|
5. Monitor for blind IDOR via timing
|
|
6. Check mobile APIs separately
|
|
7. Look for backup/debug endpoints
|
|
8. Test file path traversal
|
|
9. Automate enumeration carefully
|
|
10. Chain with other vulnerabilities
|
|
</pro_tips>
|
|
|
|
<remember>IDORs are about broken access control, not just guessable IDs. Even GUIDs can be vulnerable if disclosed elsewhere. Focus on high-impact data access.</remember>
|
|
</idor_vulnerability_guide>
|