概要
Insecure Direct Object Reference（IDOR）脆弱性は、現代のアプリケーションで最も一般的かつ危険な脆弱性クラスの一つです。概念的には広く理解されているにも関わらず、特にAPI駆動型の本番システムにおいて継続的に発生しています。IDORは、アプリケーションがユーザー提供の識別子を使用して内部オブジェクトにアクセスする際、現在のユーザーがそのオブジェクトにアクセスする権限を持っているかを検証しない場合に発生する脆弱性です。
技術的な詳細
- 脆弱性の定義: URLパス内のユーザーID、クエリパラメータ内の注文ID、リクエストボディ内のリソース識別子など、ユーザー提供の識別子を適切な認可チェックなしに直接使用することで発生
- APIでの危険性: OWASP API Security Top 10でBroken Object Level Authorization（BOLA）として最上位リスクに位置付け
- 主要なIDOR種別: 水平IDOR（同権限レベルでの不正アクセス）、垂直IDOR（特権オブジェクトへのアクセス）、ブラインドIDOR（データ露出なしでのアクション実行）
- 従来テスト手法の限界: 手動でのリクエスト再実行・比較は効果的だが時間がかかり、複雑なアプリケーションでは網羅的なカバレッジが困難
- DAST（動的解析）ツールの課題: リクエストレベルでの動作理解に限定され、オブジェクト所有権やワークフローの意図を把握できない
- 静的解析の問題: 認可チェックがミドルウェアや共有サービス層に分散実装されている場合、50%以上の誤検知率を示す
影響と対策
主な影響:
- 他ユーザーの機密データへの不正アクセス
- 他者所有リソースの変更・削除
- 所有権やロールに紐づくビジネスルールの迂回
- 承認・請求・アカウント管理ワークフローの侵害
推奨対策:
- UUIDなどの予測困難な識別子使用（ただし根本的解決にはならない）
- 文脈的な認可チェックの実装
- ランタイムでの所有権検証
- 二次的IDORに対する段階間での認可確認
重要なポイント
- IDORは単なるチェック漏れではなく、オブジェクト所有権に関連する文脈的認可の失敗である
- UUIDの使用は総当たり攻撃を防ぐが、所有権チェック不備がある場合はIDOR脆弱性を防げない
- 従来のセキュリティテスト手法では検出が困難で、実行中システムでの所有権失敗検証が必要
- システム進化の過程でワークフローの境界部分やリファクタリング時に導入されやすい