Hello there, ('ω')ノ
🧭 IDORとは？
IDOR（インセキュア・ダイレクト・オブジェクト・リファレンス） とは、Webアプリケーションがユーザーからの入力値を使って直接オブジェクト（データやファイル）を参照している場合に、攻撃者がその入力値を改ざんすることで、本来アクセスできないリソースにアクセスしてしまう脆弱性です。
🔍 例：
https://example.com/invoice?user=1001
このとき、攻撃者が user=1002 に書き換えると、他人の請求書が見えてしまう…というのが典型的なIDORです。
🕵️♂️ なぜ危険なのか？
IDORは、認証は通っているが認可チェックが不完全な場合に発生します。
- ログインしているユーザーが、自分のデータにアクセスするのは正常。
- しかし、URLやパラメータをいじるだけで他人の情報にアクセス可能なのは、設計上の重大なミスです。
🏗 なぜ発生するのか？（原因）
| 原因 | 説明 |
|---|---|
| パラメータに予測可能なIDを使用 | 例：ユーザーIDが 1001, 1002... などの連番 |
| サーバー側での認可チェックがない | セッションのユーザーと対象データの所有者が一致しているかを確認していない |
| 「URLにあるから信頼していい」という誤解 | クライアント側の値は常に信用してはいけない |
💥 IDORによる攻撃例
| 攻撃内容 | 説明 |
|---|---|
| 他人のアカウントページにアクセス | GET /profile?id=2 などの書き換え |
| 他人の注文履歴を閲覧 | GET /orders/54321 を他人の注文IDに変更 |
| 管理者機能へのアクセス（水平昇格） | GET /admin/user/3 のような直接参照 |
🛡 防御策（開発者向け）
| 対策 | 解説 |
|---|---|
| リクエストごとにユーザー権限をチェック | セッション内ユーザーとリクエスト対象が一致しているか検証 |
| オブジェクト参照にセキュアなトークンを使用 | 数値IDの代わりにランダムなUUIDやハッシュを使う |
| すべてのリクエストに認可フィルタを設置 | ロールや所有者による判定をミドルウェアで実装 |
🔄 IDORとOWASP Top 10
IDORは、OWASP Top 10（2007）で広く知られるようになり、以後も様々な年のリストで間接的に含まれています。現在は「Broken Access Control」カテゴリに分類されることが多いですが、IDORはその典型的な実装ミスのひとつです。
👨💻 IDORは簡単に見つかる一方で、被害が大きくなりがちな脆弱性です。ペネトレーションテストでは、「このIDは他人のに変えられるか？」という疑問を持って、どんなエンドポイントも観察しましょう。
Best regards, (^^ゞ
