IDOR Vulnerability Testing

IDOR 脆弱性テスト

目的

Webアプリケーションにおける安全でない直接オブジェクト参照（IDOR）脆弱性を特定し、悪用するための体系的な手法を提供します。このスキルでは、データベースオブジェクトの参照と静的ファイルの参照の両方を扱い、パラメーター操作と列挙による検出手法、Burp Suiteを使用した悪用、そして不正アクセスからアプリケーションを保護するための修正戦略について説明します。

入力 / 前提条件

• 対象Webアプリケーション: ユーザー固有のリソースを持つアプリケーションのURL
• 複数のユーザーアカウント: ユーザー間のクロスアクセスを検証するための少なくとも2つのテストアカウント
• Burp Suiteまたはプロキシツール: リクエスト操作のためのインターセプトプロキシ
• 認可: セキュリティテストに対する書面による許可
• アプリケーションフローの理解: オブジェクトがどのように参照されるか（ID、ファイル名）についての知識

出力 / 成果物

• IDOR脆弱性レポート: 発見されたアクセス制御のバイパスに関する文書
• 概念実証: ユーザーコンテキストをまたいだ不正なデータアクセスの証拠
• 影響を受けるエンドポイント: 脆弱なAPIエンドポイントとパラメーターの一覧
• 影響評価: データ露出の深刻度の分類
• 修正の推奨事項: 特定された脆弱性に対する具体的な修正策

コアワークフロー

1. IDOR脆弱性の種類を理解する

データベースオブジェクトへの直接参照

アプリケーションがユーザーが制御可能なパラメーターを介してデータベースのレコードを参照する場合に発生します:

# 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

2. 偵察とセットアップ

複数のテストアカウントを作成する

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

オブジェクト参照を特定する

以下を含むリクエストをキャプチャして分析します:

• URL内の数値ID: /api/user/123
• パラメーター内の数値ID: ?id=123&action=view
• リクエストボディ内の数値ID: {"userId": 123}
• ファイルパス: /download/receipt_123.pdf
• GUID/UUID: /profile/a1b2c3d4-e5f6-...

ユーザーIDをマッピングする

# Access user ID endpoint (if available)
GET /api/user-id/

# Note ID patterns:
# - Sequential integers (1, 2, 3...)
# - Auto-incremented values
# - Predictable patterns

3. 検出手法

URLパラメーター操作

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

HTTPメソッドの切り替え

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

4. Burp Suiteを使用した悪用

手動での悪用

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

Intruderを使用した自動列挙

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

複数の位置に対するBattering Ram攻撃

# 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

5. 一般的なIDORの発生箇所

APIエンドポイント

/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
[email protected]

クイックリファレンス

IDORテストチェックリスト

テスト	方法	脆弱性の兆候
IDの増減	id=5 を id=4 に変更	別のユーザーのデータが返される
被害者のIDを使用	既知の被害者IDに置き換える	被害者のリソースへのアクセスが許可される
範囲の列挙	IDの1～1000をテスト	他のユーザーの有効なレコードが見つかる
負の値	id=-1 または id=0 をテスト	予期しないデータまたはエラー
大きな値	id=99999999 をテスト	システム情報の漏えい
文字列ID	形式を id=user_123 に変更	ロジックのバイパス
GUIDの操作	UUIDの一部を変更	予測可能なUUIDパターン

レスポンス分析

ステータスコード	解釈
200 OK	IDORの可能性 - データの所有者を確認する
403 Forbidden	アクセス制御が機能している
404 Not Found	リソースが存在しない
401 Unauthorized	認証が必要
500 Error	入力検証の問題の可能性

一般的な脆弱なパラメーター

パラメーターの種類	例
ユーザー識別子	userId, uid, user_id, account
リソース識別子	id, pid, docId, fileId
注文/取引	orderId, transactionId, invoiceId
メッセージ/通信	messageId, threadId, chatId
ファイル参照	filename, file, document, path

制約と制限事項

運用上の制約

• 検証には、少なくとも2つの有効なユーザーアカウントが必要です
• 一部のアプリケーションでは、IDの代わりにセッションに紐づいたトークンを使用しています
• GUID/UUID による参照は列挙が困難ですが、不可能ではありません
• レート制限により、列挙の試行が制限される場合があります
• 一部の IDOR は、悪用するために連鎖的な脆弱性を必要とします

検出上の課題

• 水平的な権限昇格（ユーザー間）と垂直的な権限昇格（ユーザーから管理者へ）の違い
• レスポンスからアクセス可否が確認できない、ブラインド IDOR
• 非同期処理における時間ベースの IDOR
• WebSocket 通信における IDOR

法的要件

• 明示的な許可を得たアプリケーションのみをテストしてください
• すべてのテスト活動と検出事項を文書化してください
• 実際のユーザーデータにアクセス、変更、または持ち出しを行わないでください
• 適切な開示チャネルを通じて検出事項を報告してください

例

例 1: 基本的な ID パラメーターの IDOR

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

例 2: アドレス更新エンドポイントの IDOR

# 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

例 3: 静的ファイルの IDOR

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

例 4: Burp Intruder による列挙

# 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

例 5: 水平的から垂直的な権限昇格

# 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

トラブルシューティング

問題: すべてのリクエストが 403 Forbidden を返す

原因: サーバー側でアクセス制御が実装されています 解決策:

# 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

問題: アプリケーションが連番の ID ではなく UUID を使用している

原因: ランダム化された識別子によって、列挙のリスクが低減されています 解決策:

# 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

問題: IDOR の影響を検証できない

原因: レスポンスからデータの所有者が明確にわからないためです 解決策:

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