Insecure Direct Object References (IDOR): 10億ドルの認可バグ 🔢

はじめに：最も影響の大きいシンプルな脆弱性

URLの1つの数字を変えるだけで—例：user_id=123 から user_id=124 に—他人の医療記録や銀行明細、プライベートメッセージにアクセスできてしまう。これは高度なツールやゼロデイ攻撃を必要としない、Insecure Direct Object Reference (IDOR)です。現代Webアプリケーションにおいて最も見落とされがちな、しかし最も壊滅的な脆弱性の一つです。

セキュリティ意識が浸透しているにも関わらず、IDORの脆弱性はリテールやECのバウンティ対象の約15%、政府（18%）、医療技術（36%）、専門サービス（31%）のプログラムで最上位の脆弱性となっています。経済的な影響は計り知れず、アクセス制御の失敗によるデータ漏洩のコストは年間数十億ドルにのぼります。

そもそもIDORとは何か？

IDORの基本は、アプリケーションがユーザー提供の入力に基づき、データベースのレコードやファイル、ユーザーアカウントなどのオブジェクトに直接アクセスさせることです。ただし、適切な認可チェックが行われていない場合に起こります。アプリは、オブジェクトの識別子を参照できればアクセスできると信頼しています。

典型的な例を見てみましょう：

https://banking.example.com/api/statement?account_id=98765

もしアプリが認証済みユーザーが実際に所有している 98765 の口座を確認しなければ、攻撃者はパラメータを 98764 や 98766 に変更して他の顧客の金融明細にアクセスできてしまいます。この根本的な問題は、認可の検証が欠落していることにあります。

IDORはOWASPのトップ10の「Broken Access Control」に分類され、その深刻さを示しています。複雑な脆弱性と異なり、IDORはシンプルですが、そのシンプルさゆえに危険性は変わりません。

IDOR攻撃の仕組み

IDORの現れ方

IDORの脆弱性はさまざまな形でアプリケーション内に存在します：

1. URLパラメータ 最も一般的な形態で、オブジェクト識別子がURLに直接含まれる例：

/profile?user_id=1337
/invoice.pdf?doc_id=5829
/messages?conversation_id=abc123

2. APIエンドポイント 現代アプリはAPIに大きく依存しており、これもIDORの温床です：

POST /api/v1/user/update
{
  "user_id": "549302",
  "email": "attacker@email.com"
}

3. 隠しフォームフィールド ユーザーには見えないPOSTリクエスト内のパラメータ：

input type="hidden" name="order_id" value="88291"
input type="hidden" name="user_guid" value="a8f5f167"

4. Cookieやヘッダー あまり目立たない場所にオブジェクト参照が隠れている例：

X-User-ID: 12345
Authorization: Bearer eyJ1c2VyX2lkIjoxMjM0NX0=

IDORの種類

セキュリティ専門家はIDORをいくつかのタイプに分類しています：横方向IDORは同じ権限レベルの他ユーザのデータにアクセスさせ、縦方向IDORはより高い権限のデータにアクセスさせます。オブジェクトレベルのIDORはオブジェクトの変更や削除を可能にし、関数レベルのIDORは不正な操作や機能へのアクセスを許します。

実世界の影響：数百万ドルの損失

重要なIDOR発見例

バグバウンティコミュニティは数千のIDOR事例を記録しており、いくつかは高額の報酬を獲得しています：

• PayPalビジネスアカウントに二次ユーザを追加できるIDORで$10,500獲得
• HackerOneの認証システムの削除脆弱性で$12,500
• 銀行アプリのIDORで他ユーザの取引データにアクセスし、$3,500のバウンティ
• HackerOneのbugs.jsonエンドポイントを通じてプライベートレポートの詳細を公開

経験豊富なバグバウンティハンターは、キャリアの中で数多くのIDORを発見し、約2億5千万件のレコード漏洩に関与したと報告しています。この統計だけでも、これらの脆弱性がいかに多くの敏感データを露出させ得るかを示しています。

脅威にさらされる業界

どの業界もIDORのリスクから免れません：

医療：医療記録、処方データ、患者情報 金融：銀行明細、取引履歴、クレジットカード情報 EC：注文履歴、支払い情報、配送先住所 ソーシャルメディア：プライベートメッセージ、連絡先リスト、位置情報 SaaSプラットフォーム：ビジネスデータ、顧客記録、分析データ

アクセス制御の欠陥、特にIDORは2024年のデータ漏洩の大きな要因の一つです。ある研究者は、複数組織のAPI接続を改ざんできる脆弱性を発見し、サービスの大規模な停止やデータ漏洩を引き起こす可能性を指摘しています。

なぜIDORは2025年も続くのか

10年以上前から文書化されているにも関わらず、IDORの脆弱性は現代アプリに根強く残っています。その原因は以下の通りです：

1. 検出の難しさ

IDORは自動化ツールだけでは検出できず、手動のセキュリティテストや創造性が必要です。スキャナが活動を検知しても、分析と評価には人の目が不可欠です。従来のペネトレーションテストでは、すべてのエンドポイントのパラメータを調査しないと見逃す可能性があります。

2. 開発の複雑さ

フロントエンド、APIゲートウェイ、マイクロサービス、データベースといった複数層にまたがる現代アプリでは、認可ロジックを一貫して実装することが難しいです。どこか一つの層での見落としがIDORにつながります。

3. UUIDの誤解

UUID（ユニバーサル一意識別子）を使えばIDを推測しにくくなると考える開発者もいますが、これだけでは不十分です。UUIDが他のエンドポイントで漏れる場合や、推測可能なパターンを持つ場合もあります。UUIDが漏れるとIDORのリスクは残ります。

4. APIファースト開発

APIを優先しすぎて、各オブジェクトエンドポイントに適切なアクセス制御を実装しないケースが多いです。これによりIDORが生じやすくなります。

2025年の高度なIDOR攻撃技術

セキュリティ対策が進化するにつれ、攻撃手法も高度化しています。2025年には、単純なパラメータ操作だけではなく、より複雑な技術が必要となっています：

1. ブラインドIDOR

結果がすぐに見えない攻撃例： - 他ユーザの保存アイテムを削除（確認できない） - メールアドレスを変更（反映は静かに行われる） - 他人のサービス退会（フィードバックなし）

これらには、複数のテストアカウントを作成し、クロスアカウントの影響を監視するなどの工夫が必要です。

2. エンコード・ハッシュ化された参照

アプリは識別子をエンコードやハッシュ化している場合があります：

/document?id=ZTRkYTNiN2ZiYmNlMjM0NWQ3NzcyYjA2NzRhMzE4ZDU

これはbase64エンコードされたもので、MD5ハッシュにデコードされることもあります。攻撃者はこれを解読・クラック・パターン発見し、IDORを悪用します。

3. マスアサインメント脆弱性

攻撃者は意図しないパラメータを注入することがあります：

POST /api/update_profile
{
  "username": "attacker",
  "bio": "新しい自己紹介文",
  "user_id": "12345",  // 注入されたパラメータ
  "role": "admin"       // 権限昇格の試み
}

アプリがすべてのパラメータを無条件に処理すると、不正な変更を許す可能性があります。

4. レースコンディションIDOR

IDORとタイミング攻撃を組み合わせることで、防御を突破できる場合があります。複数リクエストを同時に送信し、一時的に認可チェックが未完了の状態を狙います。

5. GraphQL・REST APIのIDOR

最新のAPIアーキテクチャは新たな攻撃面を生み出しています。特にGraphQLは複雑なネストリクエストを許し、フロントエンドの制限を回避できる場合があります：

query {
  user(id: "target_user_id") {
    email
    phone
    creditCards {
      last4digits
      expiryDate
    }
  }
}

IDORの発見：バグバウンティハンターの手法

リコンナサンスフェーズ

IDORはアプリ全体に潜んでいるため、IDを見つけたら常にテストを行う必要があります。GUIDや暗号化された値に見えても例外ではありません。

ステップ1：アプリのマッピング - 複数のテストアカウントを作成し、権限レベルを変える - 各アカウントの利用可能な機能を記録 - オブジェクト識別子を受け付けるエンドポイントを洗い出す

ステップ2：通信のインターセプト Burp Suiteなどのツールを使い、すべてのリクエストを捕捉： - HTTP GET/POST - APIコール（REST、GraphQL、SOAP） - WebSocketメッセージ - SPAのAJAXリクエスト

ステップ3：オブジェクト参照のカタログ化 すべてのパラメータをリストアップ： - id, uid, user_id, account_id - doc_id, file_id, attachment_id - order_id, transaction_id, invoice_id - GUID、UUID、エンコードされた識別子

テストフェーズ

パラメータ改ざん 基本的なIDORテスト：値を変更してみる例：

オリジナル：/api/orders/12345
テスト1：   /api/orders/12344  (デクリメント)
テスト2：   /api/orders/12346  (インクリメント)
テスト3：   /api/orders/1      (境界値)
テスト4：   /api/orders/99999  (高値)

クロスアカウントテスト 複数アカウントを使い、他人のオブジェクトにアクセスできるか試す： 1. ユーザAがリソースを作成・アクセス（IDを記録） 2. ユーザBがそのIDを使ってアクセス 3. 応答にデータ漏洩や不正アクセスがないか確認

ブラインドテスト 即時のフィードバックがない操作： 1. ユーザAがリソースを作成（住所やウィッシュリストなど） 2. ユーザBがそのIDを使って削除・変更を試みる 3. ユーザAが影響を受けたか確認

パラメータインジェクション 不要なパラメータを追加：

// オリジナルリクエスト
{"email": "user@example.com"}

// user_idを注入
{"email": "user@example.com", "user_id": "target_id"}

高度な発見技術

スケールでの列挙 Burp Intruderやカスタムスクリプトを使い、識別子の範囲をテスト：

for user_id in range(1000, 2000):
    response = request(f"/api/profile?id={user_id}")
    if response.status_code == 200:
        analyze_data(response)

JavaScript解析 公開プロフィールや投稿からIDの漏洩やパターンを探し、自動生成したIDをテスト：Burp SuiteのIntruderや類似ツールを利用。フロントエンドのJavaScriptはAPIエンドポイントや識別子のフォーマットを明かすことがあります。

モバイルアプリのテスト モバイルアプリはAPIにユーザIDを問い合わせることが多く、これを操作して他人の情報を閲覧できる場合があります。Burp Suite Mobile Assistantやmitmproxyを使ってトラフィックをインターセプトしましょう。

予防策：認可の正しい構築

開発者向け

1. 強固な認可チェックを実装 すべてのエンドポイントは以下を検証すべき：

def get_user_order(order_id, current_user):
    order = database.get_order(order_id)
    
    # 重要な認可チェック
    if order.user_id != current_user.id:
        raise UnauthorizedException("アクセス拒否")
    
    return order

2. 間接オブジェクト参照を使用 内部IDを直接公開せず、UUIDやランダム文字列のような予測困難なトークンを使う。サーバはこれらのトークンを内部IDにマッピングし、セッションと紐付ける。

# セッション固有の参照を生成
session_token = generate_secure_token()
session_map[session_token] = {
    'user_id': current_user.id,
    'object_id': actual_object_id
}
return session_token

3. ユーザ入力の厳格な検証 すべての入力パラメータは形式、長さ、内容を検証し、サーバ側で行う。クライアント側の検証は容易にバイパスされるため。

4. クエリスコープの設定 データベースクエリは認証済みユーザに基づき自動的にフィルタリング：

-- 脆弱なクエリ
SELECT * FROM orders WHERE id = ?

-- セキュアなクエリ
SELECT * FROM orders WHERE id = ? AND user_id = ?

5. 総合的なテスト - 自動認可テストをCI/CDに組み込む - セキュリティコードレビューを定期的に実施 - ペネトレーションテストを行い、認可制御を検証

セキュリティチーム向け

多層防御 複数の認可層を実装： - ゲートウェイ認証 - サービス認可 - データベースアクセス制御 - すべてのオブジェクトアクセスの監査ログ

セキュア・バイ・デザイン フレームワークやWebアプリの設計者は、認証と認可のチェックを標準とし、セキュアな設計・デフォルトを徹底すべきです。

IDORバグバウンティの統計とトレンド

現状

HackerOneでの有効な脆弱性は過去1年で12%増加し、1,300以上のプログラムで78,042件の問題が報告されています。セキュリティ態勢は向上していますが、脆弱性の絶対数は増え続けています。毎月200件以上のIDORが安全に報告されており、この脆弱性の根強さを示しています。

なぜIDORは依然としてトップバウンティ対象なのか

いくつかの理由があります：

1. 高いインパクトと明確な証拠：IDORは不正アクセスの証拠を提供
2. スケーラビリティ：一つのIDORで何千何万のレコードにアクセス可能
3. ビジネスロジックの理解：自動スキャンだけでは見つからず、アプリ理解が必要
4. 一貫した報酬：企業はその深刻さを認識し、継続的に報酬を支払う

テストの進化

セキュリティ研究者はスキルを高め、モバイルやAPI、AIの展開に注力しています。これにより、IDORのテストは次のように進化しています： - 複雑なAPI認可フロー - GraphQLクエリの操作 - マイクロサービスの脆弱性 - クラウドネイティブアプリのテスト

よくある誤解と落とし穴

“UUIDを使っているから安全”

UUID（例：550e8400-e29b-41d4-a716-446655440000）は推測しにくいですが、IDORリスクを排除しません： - UUIDが他のエンドポイントから漏れる可能性 - ブルートフォースやパターン探索で見つかる可能性 - 認可の欠落は解決しません

“IDは暗号化されている”

暗号化は一種の隠蔽ですが、認可を置き換えるものではありません。サーバがIDを復号し、アクセス権を確認しない場合はIDORです。

“認証済みユーザだけがAPIにアクセスできる”

認証（本人確認）と認可（アクセス権付与）は別の問題です。ログインしていても、すべてのリソースにアクセスできるわけではありません。

“API呼び出しにレートリミットをかけている”

レートリミットは大量アクセスを防ぎますが、ターゲットを絞ったIDOR攻撃を止めません。攻撃者は少数の不正レコードにアクセスするだけで脆弱性を示せます。

セキュリティ全体の観点

Broken Access Control：大きな枠組み

IDORはOWASP Top 10の「Broken Access Control」の一部であり、最も発見されやすい脆弱性です。このカテゴリーには： - 機能レベルのアクセス制御欠如 - Insecure direct object references - パストラバーサル - 認証ページへの強制ブラウジング - メタデータ操作

経済的影響

IDORの具体的な金額は難しいですが、全体像は明らかです： - データ漏洩のコストは平均約4.88百万ドル - バグバウンティで重要な脆弱性を特定し、数千ドルの報酬を得るケースも - これらの脆弱性を防ぐことで、数十億ドルのコスト削減が可能

バグバウンティは長期的なコスト削減と、内部セキュリティチームの補完に役立っています。

ツールと技術

必須バグバウンティツール

Burp Suite：HTTPリクエストのインターセプトと改ざんの定番ツール Postman：APIテストと自動化 OWASP ZAP：無料のWebアプリ脆弱性スキャナ Burp Intruder：パラメータの自動テスト カスタムスクリプト：PythonやJavaScriptで大規模識別子列挙

新興技術

最新のIDOR探索は次のようなツールや手法を含みます： - GraphQL専用ツール（GraphQL Voyager, InQL） - モバイルトラフィックのインターセプト（Frida, Objection） - APIファジングフレームワーク（RESTler, Dredd） - クラウドネイティブセキュリティスキャナ

結論：10億ドルのパラドックス

Insecure Direct Object Referencesは、理解は簡単ながら完全に排除するのは非常に難しい脆弱性です。根本的なミスは、ユーザ提供の識別子に認可チェックを行わないことにあります。これは現代アプリに多様な形で現れます。

組織は次のことを徹底すべきです： - セキュリティ優先の開発 - 総合的な認可テスト - バグバウンティを通じた外部研究者との連携 - アクセス制御の継続的な監視と検証

セキュリティ研究者にとって、IDORは高収益かつインパクトのある脆弱性です。成功には： - アプリのロジック理解 - 自動化ツールを超えた創造的思考 - 攻撃面全体の体系的テスト - 明確で詳細な脆弱性レポート

マイクロサービスやAPI、クラウドネイティブアーキテクチャの進展とともに、新たなIDORの脅威が出現しますが、基本原則は変わりません：ユーザ提供のオブジェクト参照には、明示的な認可検証なしに信頼してはならない。

次にURLにIDパラメータを見つけたら、その数字が重大なセキュリティ脆弱性の鍵になり得ることを思い出してください。バグバウンティの報酬は数千ドル、あるいはそれ以上の損害を防ぐための重要なポイントです。2025年以降も、IDORは開発者とセキュリティ研究者の両方にとって挑戦と報酬の源泉であり続けるでしょう。

---

安全に留意し、徹底的にテストし、すべてのオブジェクト参照は証明されるまでは潜在的な脆弱性です。