不安全な直接オブジェクト参照（一般にIDORと呼ばれます）は、アプリケーションの脆弱性クラスの中で最も一般的で被害の大きいものの1つであり続けています。概念レベルでは十分に文書化され、広く理解されているにもかかわらず、特に最新のAPI駆動型アプリケーションにおいて、実際の運用システムで出現し続けています。
IDOR脆弱性は、アプリケーションがユーザー提供の識別子を使用して内部オブジェクトにアクセスする際に、現在のユーザーがその特定のオブジェクトにアクセスする権限があることを検証しない場合に発生します。この問題は、より広範なアクセス制御の不備のカテゴリに属しますが、その現れ方と、完全に排除することが難しい理由において独特です。
IDORは、チームが認識していないからではなく、実際のシステムがどのように進化するかから生じるため、存続します。それらは、ワークフローの端、リファクタリング中、または元々接続されるように設計されていなかったステップ間で所有権の仮定が再利用されるときに導入されることがよくあります。この記事では、IDORが実際にどのように見えるか、一般的なセキュリティテストアプローチがそれらを確実に検出するのに苦労する理由、および最新のテスト技術が実行中のシステムにおける所有権の失敗をどのように検証するかを説明します。
実際に不安全な直接オブジェクト参照とは
IDOR脆弱性は、アプリケーションがレコード、ドキュメント、アカウントなどの内部オブジェクトを参照する識別子を受け入れ、そのオブジェクトに対する認証を一貫して強制することなく、直接使用する場合に発生します。
識別子は一般的に以下のように表示されます：
- URLパス内のユーザーID
- クエリパラメータ内の注文または請求書ID
- リクエストボディ内のリソース識別子
脆弱性は識別子自体ではありません。脆弱性は、その識別子が認証されたユーザーに属するという仮定にあり、その仮定をサーバー側で再検証することなく使用される点にあります。
最新のアプリケーションでは、この前提は多くの場合当てはまりますが、すべてではありません。その不整合がIDORの発生源となります。
APIにおいてIDORの脆弱性が特に危険な理由
APIセキュリティの文献では、IDORはしばしばBroken Object Level Authorization (BOLA) と呼ばれ、OWASP API Security Top 10における最大の脅威です。OWASPは、現代のAPI設計に合わせるためにBOLAという用語に移行しました。
APIはコアとなるアプリケーション機能とデータを公開します。APIにIDORが存在する場合、攻撃者はしばしばそれを大規模にエクスプロイトできます。
一般的な影響は以下の通りです：
- 他のユーザーに属する機密データへのアクセス
- 他者が所有するリソースの変更または削除
- 所有権やロールに紐づくビジネスルールの回避
- 承認、請求、アカウント管理などのワークフローの阻害
APIは自動化のために設計されているため、単一の所有権チェックの欠落がシステムの大規模な部分を危険にさらす可能性があります。
IDORの脆弱性の一般的な種類
IDORは包括的な用語です。実際には、チームはいくつかの繰り返し現れるパターンに遭遇します：
- 水平IDOR：ユーザーが同じ権限レベルで他のユーザーのオブジェクトにアクセスする
- 垂直IDOR： 識別子によって特権または管理オブジェクトへのアクセスが可能になる
- ブラインドIDOR： レスポンスはデータを公開しないが、アクションは他者のオブジェクトに対して成功する
ブラインドIDORは、明白なデータ公開に焦点を当てるツールでは特に見過ごされやすいです。影響を確認するためには、明示的な検証がしばしば必要です。
IDORの脆弱性が実際にはどのように伝統的にテストされるか
ペネトレーションテスト中、IDORテストは通常、慎重なリクエストのリプレイと比較を通じて実行されます。
実際には、これには以下が含まれます：
- 正当なユーザーとして認証する
- UIを通じてワークフローを実行する
- ブラウザまたはクライアントによって送信されたリクエストをキャプチャする
- 別の認証済みユーザーでそれらのリクエストをリプレイする
- 動作が変化するかどうかを確認するためレスポンスを比較する
例えば、ユーザーAのデータのみを返すはずのリクエストが、ユーザーBとしてリプレイされたときに同じデータを返す場合、これはアクセス制御の不備を示します。
このアプローチは効果的であり、広く利用されています。これは、テスターのアプリケーションの意図に対する理解と、どのリクエストがセキュリティ上機密であるかを推論する能力に依存します。
しかし、これは本質的に手作業であり、時間もかかります。追加される各ワークフロー、ロール、または状態遷移は、キャプチャ、リプレイ、および解釈が必要なリクエストの数を増加させます。アプリケーションがより複雑になるにつれて、この比較を可能なすべてのパスにわたって網羅的に適用することは非現実的になります。
このため、手動テストでは注目度の高い領域でIDORを頻繁に発見しますが、包括的なカバレッジを保証することはできません。
DASTツールが実際のIDOR脆弱性を見逃す理由
動的アプリケーションセキュリティテスト（DAST）ツールはリクエストレベルで動作します。これらはエンドポイントをクロールし、入力をファジングし、異常なレスポンスを探します。しかし、それらは意図を理解しません。スキャナーは、特定された請求書がユーザーAに属するかユーザーBに属するかを知りません。所有権、ワークフローのコンテキスト、または認証されたIDに対してレスポンスが適切であるかどうかを推論しません。アプリケーションがクリーンに、多くの場合200 OKで応答する限り、スキャナーは、機密データが誤ったユーザーに公開された場合でも、そのインタラクションを成功と見なす可能性があります。
このため、DASTは表面的な問題には有用ですが、オブジェクトの所有権とコンテキストに依存するIDORやその他の認証失敗に関しては、根本的に限界があります。この制限は特定のツールに固有のものではありません。これは、リクエストレベルのスキャンが、たとえ適切に実装されていても、オブジェクトの所有権やワークフローの意図について推論するのに十分なコンテキストを持っていないという事実を反映しています。
静的解析がIDORに関するノイズを生成する理由
多くのチームは、潜在的なIDORの問題を特定するために静的解析ツールに依存しています。これらのツールは通常、識別子がハンドラーやコントローラーに渡される際に、近くに明示的な認可チェックがないパターンを探します。
これはしばしば多数の検出結果を生成します。
実際には、これらのほとんどは誤検知です。認可チェックは、コールチェーン内、共有ミドルウェア内、またはフレームワークレベルなど、他の場所に頻繁に存在します。静的解析は、識別子がランタイムでエクスプロイト可能であるかどうかを確実に判断することはできません。
認可が暗黙的に実装されている場合や、以下のように複数の層に分散されている場合、この問題は増幅されます。
- ミドルウェアまたはデコレーターによって強制されるアクセス制御
- 共有サービスまたはモデルメソッド内に実装されたチェック
- 複数のファイルとコールパスにわたって分散された権限ロジック
これらのケースでは、静的ツールは識別子とデータアクセスパスを認識しますが、完全な認可コンテキストを見落とします。その結果、もっともらしく見えるが信頼性の低い検出結果が大量に生成されます。
これは静的解析の根本的な限界です。ランタイムの状態とIDコンテキストがなければ、いかなるコードレベルの解析も、オブジェクト参照が実際にエクスプロイト可能であるかどうかを確実に判断することはできません。
AI支援静的解析ツールでさえ予測的です。それらはコード構造について推論しますが、ランタイムの動作を確認することはできません。その結果、IDORに類似する検出結果は50パーセントを超える誤検知率を伴うことが多く、チームは理論的な問題のトリアージを強いられ、その間に実際の所有権の欠陥が見過ごされるリスクがあります。
根本的な問題：所有権はコンテキストに依存する
IDORは単にチェックの欠落ではありません。それらはオブジェクトの所有権に関連するコンテキスト認可の失敗です。
所有権は以下の組み合わせによって確立されます。
- 認証状態
- ロールと権限モデル
- ワークフローの進行
- プロセスで以前に作成されたサーバーサイドの状態
そのコンテキストのいずれかの部分が再検証されずに仮定された場合、IDORが発生する可能性があります。
一部のIDORはセカンドオーダーです。識別子は1つのステップで受け入れられ、保存され、アクセス制御がチェックされなくなった後にのみ使用されます。これらの問題は、エクスプロイトが時間とステップをまたいで分離されているため、特に検出が困難です。
IDORを確実にテストするには、「この識別子が他の誰かに属している場合はどうなるか？」という単純な質問を繰り返し問いかける必要があります。
UUIDはIDORの脆弱性を防止しない
シーケンシャルな識別子からUUIDに切り替えることでIDORのリスクが排除されるというのは、一般的な誤解です。
予測不可能な識別子はブルートフォース攻撃を軽減します。しかし、所有権チェックが欠落している場合、不正アクセスを防止することはできません。
実際のシステムでは、攻撃者は以下を含む通常のアプリケーションの動作を通じて識別子を取得します。
- 他のエンドポイントから返される参照情報
- 共有リンクおよびURL
- アプリ内メッセージおよび通知
- ログ、エクスポート、およびブラウザ履歴
攻撃者が有効な識別子を取得でき、バックエンドが所有権を強制しない場合でも、IDORは依然として存在します。
AI ペンテストが他が見逃すIDORの脆弱性を発見する方法
AI ペンテストは、認証の失敗を特定するために異なるアプローチを取ります。
検出にとどまらず、実行中のアプリケーションにおいて所有権とアクセス制御に関する仮説を積極的にテストします。
Aikidoでは、このアプローチはAikido Attackを通じて実装されています。これは、人間の創造性と機械の速度を組み合わせた自律型ペネトレーションテストです。実際の環境における認可および所有権の不備を評価するように設計されています。Aikido Attackは、実際のIDを使用してワークフローをエンドツーエンドで実行し、結果を報告する前にエクスプロイト可能性を検証します。
IDORの場合、このプロセスには以下が含まれます。
- 実際のユーザーとして認証する
- エンドツーエンドで完全なワークフローを実行する
- ロールやコンテキストを超えてオブジェクト識別子を再利用する
- 他のユーザーが所有するリソースへのアクセスまたは変更を試みる
- その挙動がエクスプロイト可能であり、再現可能であるかを検証する
実際にエクスプロイト可能な問題のみが報告されます。それ以外は自動的に破棄されます。
これにより誤検知が減少し、報告された発見が実際の認証の失敗を表していることを保証します。意図が不明確な状況では、通常、人間のテスターはアプリケーション所有者と協議する必要がありますが、ランタイム検証はこれを直接解決します。
所有権の仮定に焦点を当てたテスト
AI ペンテストは、アプリケーション全体でオブジェクト識別子に結びついた所有権の仮定を評価するために、専用の労力を割り当てます。
IDORを一般的なテストの副次的な効果として扱うのではなく、明示的に以下に焦点を当てます。
- ユーザーが所有するリソースに紐付けられた識別子
- オブジェクト参照を再利用するワークフローの遷移
- フロントエンドの所有権の仮定に依存するバックエンドのエンドポイント
これにより、IDORが実際に発生するシステムの箇所において一貫したカバレッジが保証されます。
例：多段階承認ワークフローにおけるIDOR
この例は、個々のエンドポイントがアクセス制御を正しく強制しているように見える場合でも、IDORが複数のワークフローステップにわたってどのように発生しうるかを示しています。
アプリケーションコンテキスト
このアプリケーションには、機密性の高い操作のための多段階承認ワークフローが含まれています。ユーザーがリクエストを作成し、後でレビューおよび承認される必要があります。各リクエストは、それを作成したユーザーに関連付けられ、複数のAPIコールで使用される識別子によって参照されます。
リクエストの所有者のみが、承認前にそのリクエストを閲覧または変更することが意図されています。
システムが観測した内容
AI ペンテストは、標準ユーザーとして認証し、リクエスト作成フローを実行しました。このプロセス中に、システムは中間ワークフローの状態をサーバーに保存し、後続のステップで再利用しました。
リクエストが作成された際、最初のリクエスト所有権チェックは正しく適用されました。
ワークフロー全体における所有権のテスト
さらなるテストにより、リクエスト識別子が後続の段階でどのように使用されるかが評価されました。その結果、以下の点が観測されました。
- 保留中のリクエストを再開する際、識別子は再利用されました
- 後続のAPIコールは、以前の検証に基づいて所有権を前提としていました
- ワークフローが再開された際、所有権は再検証されませんでした
別の認証済みユーザーで再開アクションをリプレイし、リクエスト識別子を置き換えることで、システムは、所有していないリクエストにアクセスし、操作することが可能でした。
これがIDOR脆弱性であった理由
この問題は、単一のチェック漏れに起因するものではありませんでした。
これは、所有権がワークフローの早い段階で既に検証されており、リクエストが再開された際に再チェックする必要はないという仮定から生じました。その仮定は、オブジェクト識別子がユーザー間で再利用された時点で破綻しました。
検証と再現性
問題を報告する前に、システムは以下を実行しました。
- 完全なシーケンスを複数回リプレイしました
- 一貫した動作を確認しました
- 不正アクセスの証拠を捕捉しました
再現性と影響が確認された後にのみ、問題が報告されました。
他のアプローチではなぜこれが検出されなかったのか
個々のエンドポイントは単独では正しく動作していました。脆弱性は次の場合にのみ発生しました。
- ワークフローが部分的に完了していました
- サーバー側の状態が再利用されました
- 後続のステップが元のユーザーコンテキスト外で呼び出されました
これにより、問題は手動テストでは検出が困難であり、リクエストベースのスキャンツールでは検出できませんでした。
IDOR脆弱性にとって継続的なテストが重要である理由
IDORは多くの場合、変更によって引き起こされます。
これらは一般的に以下の場合に発生します。
- 新機能が既存のデータモデルを再利用する場合
- 認可ロジックが一部には追加されているが、他の場所には追加されていない場合
- リファクタリングによって意図せず以前の所有権チェックがバイパスされる場合
ある時点でのテストでは、現在所有権が強制されていることを確認できるかもしれませんが、アプリケーションの進化とともにその保証は低下します。
AI駆動の継続的なテストは、ソフトウェアの変更に伴い所有権の仮定を再評価することで、信頼性を維持します。継続的なペンテストツールは、新規および変更されたワークフローにおける不正なオブジェクトアクセスを継続的にテストすることで、これをサポートします。
システムの複雑性の兆候としてのIDOR脆弱性
IDORはエッジケースではありません。これらは、複雑なシステムが時間とともに進化する中で自然に発生する結果です。
アプリケーションが成長するにつれて、所有権ロジックはサービス、ワークフロー、およびレイヤー全体に拡散します。仮定が蓄積され、オブジェクトレベルのアクセスについて推論することがますます困難になります。
AIペンテストは、この複雑性を取り除くものではありませんが、テスト可能にします。
ワークフローを体系的に実行し、状態を追跡し、コンテキスト内で所有権を検証することで、最も根強い脆弱性クラスの1つを、より早期に、より一貫して、より高い信頼性で検出できるものに変えます。
セキュリティチームは、IDORやその他の認可の失敗をますます優先しています。これらはシステム固有であり、リグレッションが発生しやすく、ワークフローを認識したランタイムテストなしでは検証が困難であるためです。
こちらもおすすめ：
