IDOR（直接参照の不備）とは？
IDOR（Insecure Direct Object Reference：安全でない直接オブジェクト参照）とは、URLやフォームのパラメータに含まれるID、ファイル名、パス等を変更するだけで、本来アクセス権限のないデータやファイルにアクセスできてしまう脆弱性です。Webサイト・APIの弱点の中でも最も単純でありながら深刻な脅威で、「document.php?id=123」のIDを「124」に変えるだけで他人の書類が見えたり、「/uploads/user1/file.pdf」を「/uploads/user2/file.pdf」に変えるだけで他人のファイルをダウンロードできたりします。アクセス制御の基本が欠落している状態です。
IDOR（直接参照の不備）を簡単に言うと？
図書館の本棚に例えると、「3番の棚の本を取ってください」と言われた係員が、「あなたは3番の棚を見る権限がありますか？」と確認せずに本を渡してしまうようなものです。悪い人が「じゃあ4番の棚」「5番の棚」と次々に言えば、立入禁止の貴重書コーナーの本まで全部見られてしまいます。Webサイトも同じで、URLの「invoice/2024/001.pdf」を「invoice/2024/002.pdf」に変えるだけで、他社の請求書が見えてしまったりします。まるで、部屋番号を言うだけで合鍵がもらえるような、信じられないほど単純な穴。でも、この単純な穴で毎年数億件もの個人情報が漏れているのが現実なのです。
IDOR（直接参照の不備）で発生する被害は？
IDORにより、個人情報の大量流出、機密文書の不正取得、他者アカウントの完全掌握などが発生します。Webサイト・APIの弱点を突かれることで、攻撃者は手作業またはスクリプトで順番にIDを変更し、データベース全体の内容を抜き取ることが可能になります。特に、医療記録、給与明細、契約書など、センシティブな情報を扱うシステムでは、一つのIDORが組織全体を危機に陥れます。
IDOR（直接参照の不備）で発生する直接的被害
- 個人情報の根こそぎ窃取
顧客ID、注文番号、ユーザー番号を総当たりで変更し、全顧客の氏名、住所、電話番号、購入履歴などを自動収集されて転売される
- 機密文書の不正ダウンロード
ファイル番号やパスを推測・変更して、契約書、見積書、設計図、財務諸表などの企業秘密文書を大量にダウンロードされる
- 他者アカウントの操作
プロフィール編集画面のユーザーIDを変更して、他人のパスワード変更、メールアドレス変更、アカウント削除などを勝手に実行される
IDOR（直接参照の不備）で発生する間接的被害
- 取引先からの信頼喪失
取引先の機密情報が漏洩したことで契約解除され、損害賠償請求を受けて、ビジネス関係が完全に崩壊する
- 内部不正の温床化
従業員が他の従業員の給与明細や人事評価を覗き見できることが発覚し、組織の士気が低下して優秀な人材が流出する
- 規制当局からの処分
金融や医療分野では、IDORによる情報漏洩で営業停止処分を受け、復旧まで数年かかって市場シェアを完全に失う
IDOR（直接参照の不備）の対策方法
IDORへの対策は、間接参照の使用、アクセス制御の徹底、権限チェックの実装が基本となります。Webサイト・APIの弱点を補強するために、直接的なID露出を避け、セッションベースのアクセス制御、すべてのリソースアクセス時の権限確認が重要です。また、推測困難なUUIDの使用、アクセスログの詳細記録、異常なアクセスパターンの検知により、攻撃を防ぎ早期発見することができます。
IDOR（直接参照の不備）の対策を簡単に言うと？
ホテルの荷物預かりサービスに例えると、まず荷物に「1番、2番」という連番ではなく、推測できない「A7X9-B2K4」のような番号（UUID）をつけます。お客様が「荷物を取りに来ました」と言ったら、必ず「預かり証を見せてください」「身分証明書を確認します」と本人確認（権限チェック）をします。さらに、預かり証の番号だけでなく、その人専用の暗証番号（セッション情報）も必要にします。誰が、いつ、どの荷物を取ろうとしたか全て記録（ログ）して、「1番、2番、3番...」と順番に聞いてくる怪しい人はすぐに止めます。「番号を知っているから渡す」のではなく、「本人だと確認してから渡す」という基本を徹底することが、IDORを防ぐ鍵なのです。
IDOR（直接参照の不備）に関連した攻撃手法
Webサイト・APIの弱点において、IDOR（直接参照の不備）と密接に関連する3つの攻撃手法を解説します。
- APIの不適切な認可（BOLA）
IDORとBOLAは本質的に同じ問題を異なる視点から見たものです。IDORは「直接参照」の観点から、BOLAは「認可の破綻」の観点から同じ脆弱性を説明しています。API環境ではBOLA、従来のWebアプリケーションではIDORという用語が使われることが多いです。
- ディレクトリトラバーサル
IDORがIDやファイル名の変更なら、ディレクトリトラバーサルはパスの操作です。両者を組み合わせることで、IDORで特定したファイル名を使い、ディレクトリトラバーサルで別フォルダのファイルにアクセスするという複合攻撃が可能になります。
- SQLインジェクション
IDORで取得したIDパターンや構造情報を使って、より精度の高いSQLインジェクション攻撃を実行できます。また、SQLインジェクションで取得したデータベース構造を使って、IDORの攻撃範囲を特定することもあります。
IDOR（直接参照の不備）のよくある質問
UUIDなどランダムなIDは推測を困難にしますが、それだけでは不十分です。どこかでIDが漏れたり、総当たり攻撃を受けたりする可能性があるため、必ず権限チェックが必要です。
はい、頻繁に起こります。「ログインしている」ことと「そのデータを見る権限がある」ことは別問題です。ログイン後のユーザー間でのIDORが最も一般的です。
RESTful APIは予測可能なURL構造（/users/123、/orders/456）を使うため、IDORが発生しやすい傾向があります。設計時から認可を意識することが特に重要です。
はい、むしろ小規模サイトの方がセキュリティ対策が甘いため狙われやすいです。自動化ツールで大量のサイトをスキャンして、IDORの脆弱性を探す攻撃者もいます。
2つの異なるユーザーアカウントを作成し、URLやパラメータのIDを相互に変更して、他のユーザーのデータにアクセスできないか確認します。Burp SuiteなどのツールでAuthorization Testingを実施することも有効です。
可能ですが、慎重な対応が必要です。まず重要度の高いエンドポイントから修正し、アクセスログを強化して不正アクセスを監視しながら、段階的に全体を改善していきます。
更新履歴
- 初稿公開
