4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@luan_nguyenin株式会社TOMOSIA VIET NAM

IDOR — ソフトウェアアーキテクチャにおける「無邪気」だが致命的な脆弱性？

4
Posted at

idor.png

5つ星の高級ホテルにチェックインする場面を想像してください。最先端のセキュリティシステム、至る所に設置された監視カメラ、最新のエレベーター用ICカード。フロントスタッフから101号室の鍵を受け取り、部屋に上がって、ドアを開けて休みます。ところが、好奇心から鍵に刻まれた番号を削って「102」に書き換え、隣の部屋の鍵穴に差し込んでみると——カチャッ。ドアが開いてしまいました。

現実世界では、これは笑い話でしかありません。しかしWebとAPIの世界では、この状況があまりにも頻繁に起きるため、セキュリティ業界の「慢性的な頭痛の種」になっています。これを IDOR（Insecure Direct Object Reference：安全でない直接オブジェクト参照） 、あるいは BOLA（Broken Object Level Authorization：オブジェクトレベル認可の欠陥） と呼びます。

あなたがバックエンドエンジニアで、「Authentication（認証）さえあれば安全だ」と信じているなら——この記事はその考えを根本から変えることになるでしょう。表面的な話にとどまらず、この脆弱性のアーキテクチャ的な本質まで掘り下げていきます。

1. IDORの技術的本質

IDOR（Insecure Direct Object Reference）は単なるコードのバグではなく、ロジック設計の欠陥（Business Logic Flaw） です。

OWASP API Security Top 10において、IDORはまさに脆弱性第1位の本質そのものです： API1: 2023 Broken Object Level Authorization (BOLA).

より深く理解すると、IDORは以下の 3つの条件が重なったとき に発生します：

  1. Direct Reference（直接参照）： アプリケーションがオブジェクトの内部識別子（データベースの主キーやファイル名など）をURLまたはリクエストボディに直接露出している。
  2. User Input（ユーザー入力の信頼）： アプリケーションがその入力を検証なしにそのままデータ取得に使用している。
  3. Missing Authorization（認可チェックの欠如）： アプリケーションがオブジェクトへのアクセス権限を、取得の時点で確認していない。

よくある誤解： 多くの開発者が Authentication（あなたは誰？） と Authorization（あなたは何をしてよい？） を混同しています。IDORはAuthenticationの関門を通過した後に、システムがオブジェクトレベル（Object-level）でのAuthorizationチェックを忘れたときに発生します。

Image_eohbxheohbxheohb-1-1024x559.png

2. 攻撃メカニズムの解剖

HTTPリクエストを解剖して、IDORがどこに潜んでいるかを見てみましょう。URLパラメータだけでなく、HeaderやBodyにも隠れている可能性があります。

シナリオ： チャットアプリがユーザーにチャット履歴の取得を許可している。

GET /api/v1/messages?conversation_id=9182 HTTP/1.1
Host: chat-app.com
Authorization: Bearer eyJhbGci...  ← 認証済み（あなたは誰か）
X-User-Context: {"user_id": 5566}  ← Headerに隠れたIDOR
Content-Type: application/json

{
  "fetch_options": {
    "include_deleted": true,
    "target_user_id": 9182  ← Bodyに隠れたIDOR
  }
}
  1. ハッカーが観察する： すべてのリクエストに X-User-Context: {"user_id": 5566} というHeaderが付いていることに気づく。
  2. 試してみる： PostmanまたはBurp Suiteでリクエストを傍受し、X-User-Context: {"user_id": 5567} に書き換える。
  3. サーバーの反応： 安全なセッション（Server-side）からIDを取得する代わりに、Header（Client-side）のIDをそのまま信頼してデータベースをクエリする: SELECT * FROM messages WHERE user_id = 5567
  4. 結果： ハッカーはユーザー5567のメッセージを全件読み取ることができてしまう。

このリクエストには 3箇所 にIDORの潜伏ポイントがあります：

場所 パラメータ リスク
URL Parameter conversation_id=9182 最も一般的。数字を変えるだけで他人の会話にアクセス可能
Header X-User-Context: user_id: 5566 見落とされやすい。サーバーが信頼してしまうと致命的
Request Body target_user_id: 9182 深いところに隠れているため、コードレビューでも見逃されやすい

Authorization: Bearer token が存在しても安全とは言えません。これはAuthenticationの証明であり、各オブジェクトへのアクセス権限（Authorization）を保証するものではありません。

Image_t2k171t2k171t2k1-1-1024x572.png

3. なぜIDORは「サイレントキラー」なのか？

IDORが危険なのは、その**構文的な「正当性」**にあります。

  • WAF（Webアプリケーションファイアウォール）をすり抜ける： ファイアウォールは通常、' OR 1=1 --（SQLインジェクション）や <script>（XSS) といった不審な文字列をブロックします。しかしIDORのペイロードはただの数字：id=1006。WAFにとってこれは完全にクリーンで正当な値です。

  • 自動化ツールでの検出が困難： スキャナーはビジネスコンテキストを理解しません。スキャナーが id=1006 を送信して 200 OK が返ってくれば、「成功」とマークします。返されたデータがリクエスト送信者のものではないという事実を、スキャナーは知る術がありません。発見できるのは、人間（ペネトレーションテスター）か、丁寧に書かれたUnit Test だけです。

  • 連鎖的な被害： IDORは多くの場合、権限昇格（Privilege Escalation） への足がかりとなり、最終的にシステム全体の乗っ取り（Account Takeover）につながります。

IDORの危険性は、それが構文的な脆弱性ではなく、ロジックの脆弱性である点にあります。従来の静的セキュリティスキャンツール（SAST）がIDORの検出に失敗しがちなのは、特定のアプリケーションにおける「誰が何を所有しているか」というコンテキストを理解できないからです。

これはある逆説を生み出しています：モダンなフレームワークの普及によってSQLインジェクションのような技術的脆弱性が減少傾向にある一方で、IDORは根強く残り続け、バグバウンティプログラムにおける報告件数の上位を占め続けています——特に医療・行政・専門サービス分野において顕著です。

4. IDORの詳細な分類

4.1. 水平権限昇格（Horizontal Privilege Escalation）

これは最も一般的な形態です。同じ権限レベルを持つユーザーAが、ユーザーBのデータにアクセスします。

  • 具体例： 注文履歴の閲覧、請求書のダウンロード、プライベート画像の閲覧
  • リスク： 個人情報漏洩（PII Breach）、GDPR/CCPA違反

4.2. 垂直権限昇格（Vertical Privilege Escalation）

一般ユーザー（User）が、管理者（Admin/Manager）専用のAPIを呼び出そうとする形態です。

具体例：

# ハッカーが管理者用APIを発見
POST /api/users/1001/roles
Authorization: Bearer <token_of_normal_user>
Content-Type: application/json

{
  "role": "ADMIN"
}

権限昇格の流れ

  ハッカー（一般ユーザー）                    サーバー
        │                                      │
        │  POST /api/users/1001/roles          │
        │  {"role": "ADMIN"}  ────────────────▶│
        │                                      │  ❌ 「呼び出し元はSuper Adminか？」
        │                                      │     チェックなし
        │                                      │
        │  200 OK  ◀────────────────────────── │  UPDATE users SET role='ADMIN'
        │                                      │
        ↓
  一般ユーザー → ADMIN に昇格完了
水平昇格との違い 水平権限昇格 垂直権限昇格
対象 同じ権限レベルの他ユーザーのデータ より高い権限レベルの機能・データ
被害範囲 特定ユーザーの情報漏洩 システム全体の乗っ取りが可能
深刻度 高い 致命的

4.3. 静的ファイルに対するIDOR（Static File IDOR）

ファイル名は通常、推測しやすいものです。

  • 例えば、https://example.com/uploads/receipts/receipt_001.pdf のような形です。
  • ハッカーはスクリプトを書いて「001」から「9999」までループ処理させ、システムのすべての領収書をダウンロードしてしまいます。

5. 実例：業界の「巨人」たちが犯した過ち

5.1. マクドナルドと「McHire」のデータ流出インシデント（2025年7月）

Link: https://research.cgu.edu/icdc/2025/07/01/mcdonalds-july-2025-breach/

背景： 今回影響を受けたシステムは、マクドナルドのグローバル採用プラットフォーム McHire です。このプラットフォームはサードパーティのテクノロジーパートナーである Paradox.ai によって運営されています。Paradox.aiは 「Olivia」 というAIチャットボットソリューションを提供しており、面接プロセスの自動化、応募者情報の収集、シフトスケジューリングを担っています。このサードパーティへの依存が、マクドナルドの攻撃対象領域（Attack Surface）を、自社が直接管理するインフラの外側にまで拡大させていました。

主な原因： このインシデントは2つの深刻な欠陥が組み合わさって発生しました。

  1. 認証の脆弱性（Weak Authentication）

    • Paradox.aiのテスト用管理者アカウントがパスワード「123456」を使用しており、MFAも未設定
    • このアカウントは2019年から存在し続け、本番環境へのアクセス権限を持ったまま無効化されていなかった

  2. IDORの脆弱性（Missing Object Level Authorization）

    • バックエンドAPIが applicant_id を使って応募者プロフィールを取得できる仕様
    • アクセス権限のチェックなし → IDを変えるだけで任意の応募者データを読み取れる状態
    • たった1つのアカウントから → 全世界6,400万件のプロフィールへの拡大アクセスが可能に

影響範囲：

  • PII漏洩： 氏名・メールアドレス・電話番号・自宅住所
  • 機密データの露出： AIとのチャットログ（性格・趣味・個人的な情報）
  • セッショントークンの漏洩： 応募者へのなりすましが可能に
  • 高いリスク： ソーシャルエンジニアリング・詐欺・アカウント乗っ取りへの悪用

ずさんなアカウント管理（幽霊アカウント・MFAなし）とAPIレベルの認可欠如（IDOR）の組み合わせは、グローバル規模のデータ漏洩における「パーフェクトストーム」を生み出します——2025年において、これは極めて深刻な警告トレンドと言えます。

5.2. Mozilla Firefox Accounts — アカウント削除の脆弱性（2025年5月）

Link: https://hackerone.com/reports/3154983

インシデントの本質:

  • アカウント削除API（/v1/account/destroy）における深刻なIDOR脆弱性。
  • 被害者の操作を一切必要とせず（ゼロクリック）、他者のアカウントを永久削除することが可能。
  • データの**完全性（Integrity）および可用性（Availability）**に直接影響を及ぼす。

技術的原因:

  • セッションミスバインディングの欠陥：バックエンドが、作業セッションと削除対象アカウントの一致を検証していない。
  • APIがリクエスト送信者のセッションではなく、JSONペイロード（email、authPW）を信頼している。
  • これは書き込み/削除型のIDORであり、データ読み取り型IDORよりも危険度が高い。

攻撃シナリオ:

  1. 攻撃者がFirefoxアカウントを作成し、SSO（Google）でログインする。
  2. 自身のアカウント削除リクエストをインターセプトする。
  3. ペイロード内のemailを被害者のメールアドレス（SSO利用中、パスワード未設定）に書き換える。
  4. リクエストを送信 → システムが被害者のアカウントを削除する。

影響:

  • データの永久喪失：保存済みパスワード、閲覧履歴、タブ、同期データ。
  • 復元不可能であり、被害者のクリックや承認も一切不要。
  • HackerOneにてCritical（最高深刻度）と評価済み。

核心的な教訓
IDORはデータの漏洩（読み取り）を引き起こすだけでなく、バックエンドがセッションとリソースオブジェクト間の紐付けを厳密に検証しない場合、データの破壊（書き込み／削除）をも引き起こし得る。

5.3. GitLab – 機械学習モデルレジストリの脆弱性（2024〜2025年）

Link: https://hackerone.com/reports/2528293

背景

  • GitLabはAIモデルのバージョン管理を目的として、機械学習モデルレジストリを導入した。
  • 脆弱性は2024年5月に報告され、パッチ適用および公開は2025年にかけて長期化し、大規模プラットフォームにおけるセキュリティの複雑さを示した。
  • 本インシデントはAI知的財産（モデルの重みおよびバイアス）に直接影響を及ぼした。

技術的原因

  • GitLabはランダムなUUIDの代わりに、model_idに連番ID（1、2、3…）を採用していた。
  • モデルのダウンロード・閲覧APIがプロジェクトへのアクセス権限を検証していなかった（オブジェクトレベル認可の欠如）。
  • これは典型的なIDORと不十分なAPI設計が組み合わさった事例である。

攻撃手法

  • 攻撃者は無料のGitLabアカウントさえあれば実行可能。
  • IDを1から数百万まで順番に試すことで、他プロジェクトのモデルを列挙・ダウンロードできる。
  • ブルートフォース不要、プロジェクト権限も不要。

影響

  • 企業の独自MLモデルが流出するリスク。
  • AIがコア資産となっている現状において、企業秘密の喪失および多大な経済的損失を招く恐れ。
  • 脆弱性は自動化・大規模なenumeration攻撃による悪用が可能。

核心的な教訓
公開APIに連番IDを使用してはならない。それはIDORを潜在的な脆弱性から大量悪用可能な重大インシデントへと変貌させ、AI資産に対しては特に危険である。

6. IDORの効果的な防止策（ベストプラクティス）

テストアカウント1つで6,400万件のレコードにアクセスでき、1通のメールで他人のアカウントを削除でき、1つの連番で企業のAIモデルを根こそぎ奪える――これは明らかに「ハッカーが優秀すぎる」問題ではない。正しい方法でIDORを防ぐことが求められているのだ。

image.png

「クライアントを決して信頼するな」
以下は多層防御戦略（Defense in Depth）である。

レイヤー1：データ層でのアクセス制御（Data-Layer Authorization）

これは最後にして最も重要な防衛線である。ユーザーデータに関わるすべてのクエリには、所有者に関する条件を必ず付加しなければならない。

❌ リスクのあるコード（PHP / Laravel）：

// Controller
public function getOrder($id)
{
    return Order::find($id); // ID注文のみで検索（危険）
}

✅ 安全なコード（Repository Pattern）：

// Repository
// 常にuserIdをクエリに付加する
public function findByIdAndOwner(int $id, int $currentUserId): ?Order
{
    return Order::where('id', $id)
                ->where('user_id', $currentUserId)
                ->firstOrFail(); // 見つからない場合は404を返す
}

// Service Layer
public function getOrder(int $id, User $currentUser): Order
{
    return $this->orderRepository->findByIdAndOwner($id, $currentUser->id)
        ?? throw new ModelNotFoundException('Order not found or access denied');
}

レイヤー2：コントローラー層でのアクセス制御（Method-Level Security）

フレームワーク（Laravel Policyなど）のセキュリティ機能を活用し、入口の段階でアクセスを遮断する

✅ Controller層でのアクセス制御（Laravel Policy / Middleware）:

// Laravelのauthorize()を使用 — Spring @PreAuthorize に相当
public function show($id)
{
    $invoice = Invoice::findOrFail($id);

    // ポリシーチェック: 現在のユーザーがこのinvoiceの所有者である場合のみ許可
    $this->authorize('view', $invoice);

    return response()->json($invoice);
}

// app/Policies/InvoicePolicy.php
public function view(User $user, Invoice $invoice): bool
{
    return $user->id === $invoice->user_id;
}

この方法によりビジネスロジックのコードがより整理され、セキュリティロジックとビジネスロジックを明確に分離できる。

レイヤー3：UUIDによる攻撃者への難読化（Obfuscation）

Auto-Increment Integer（1, 2, 3）の代わりに、UUID（ランダム文字列：a0eebc99-9c0b...）またはID ハッシュアルゴリズム（Hashidsなど）を使用する。

  • メリット： enumeration攻撃を完全に遮断できる。攻撃者はfor (i=0; i<1000; i++)のようなループでデータをスキャンすることができなくなる。
  • 注意： UUIDはレイヤー1およびレイヤー2の代替にはならない。仮に攻撃者が何らかの方法で被害者のUUIDを入手した場合、認可チェックが欠如していればIDORは依然として発生する。UUIDはあくまで「霧のベール」であり、「鉄壁の防御」ではない。

レイヤー4：自動セキュリティテスト（Automated Security Testing）

ペンテスターが脆弱性を発見するのを待つのではなく、IDOR向けのテストケースを自動化して記述する。

  • ユニットテスト： 2人のユーザー（AliceとBob）を作成する。Aliceとしてログインし、BobのIDのデータをリクエストする。レスポンスが403 Forbiddenまたは404 Not Foundであることをアサートする。

7. 結論

IDORは技術的に複雑なバグではないが、システム設計思想における欠陥を如実に反映している。

黄金原則を忘れてはならない：データアクセスに関わるすべてのリクエストは、以下の2つの問いに答えられなければならない。

  1. このユーザーは誰か？（Authentication／認証）
  2. このデータはそのユーザーのものか？（Authorization／認可）

2つ目の問いが欠如している場合、「101号室」の鍵を持つ者なら誰にでも「102号室」の扉を大きく開け放っていることになる。

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?