IDORの脆弱性を理解し検出する

APIは最新のアプリケーションをつなぐ結合組織であり、シームレスなデータ交換と機能連携を可能にします。しかし、この連携性は潜在的なセキュリティリスクももたらします。APIに見られる最も一般的で、かつ被害の大きい可能性がある脆弱性の一つが**安全でない直接オブジェクト参照（Insecure Direct Object Reference、IDOR）**です。OWASP Top 10にも頻繁に挙げられており、アプリケーションとユーザーデータを保護するにはIDORの理解と緩和が不可欠です。

この記事では、IDORとは何か、攻撃者がAPIにおいてどのようにIDORを悪用するか、そしてAikido SecurityのAIペネトレーションテスト機能を活用してこれを事前に検出する方法を解説します。

IDORとは正確には何か

あなたがアパートに住んでいると想像してください。あなたの鍵（認証）は正面玄関とあなたの部屋（例: #101）に入ることを許可します。IDORの脆弱性とは、たとえ自分の鍵が#101用であっても、部屋番号（#102など）さえ知っていればそのドアを開けられてしまうシステムのようなものです。

技術的に言うと、IDORはアプリケーションが内部オブジェクト（データベースレコード、ファイル、ユーザープロファイルなど）への直接アクセスに識別子を使用するが、現在のユーザーがその特定のオブジェクトへのアクセスを実際に許可されているかを確認する適切な認可チェックを行わない場合に発生します。

この「識別子」は、多くの場合ユーザー/クライアントによって提供されるもので、例えば以下のようなものです。

URLパス内のユーザーID（/api/users/12345）
クエリパラメータ内の注文ID（/api/orders?id=9876）
リクエストボディ内のドキュメントID（{"documentId": "abc-def"}）

脆弱性の本質は識別子の使用そのものではなく、ログイン中のユーザーがその識別子が指すリソースへのアクセス権を持っているかの検証が欠けていることにあります。

なぜIDORは、特にAPIにおいて危険なのか

APIはアプリケーションの中核機能やデータを公開することが多いため、APIにおけるIDORの脆弱性は以下につながる可能性があります。

データ漏洩: 攻撃者は識別子を反復操作（例: /api/users/101 を /api/users/102、/api/users/103 などに変更）することで、他のユーザーに属する機密情報（個人情報、金融データ、プライベートメッセージなど）にアクセスできます。
不正な操作: 攻撃者はPUT、POST、DELETEリクエスト内の識別子を操作することで、他人が所有するデータを変更または削除できる可能性があります（例: 削除リクエストで /api/orders/555 を /api/orders/556 に変更）。
権限昇格: 場合によっては、他のユーザーのデータや設定にアクセスすることで、間接的により高い権限を得られることがあります。
ビジネスロジックの欠陥: IDORは、請求書、レポート、システム構成などのリソースへの不正な操作を許すことで、ビジネスプロセスを混乱させる可能性があります。

攻撃者がAPIスキャンでIDORを悪用する方法

攻撃者は多くの場合、自動化ツールや簡易スクリプトを使ってAPIのIDOR脆弱性を調べます。一般的なプロセスは以下の通りです。

発見: パス、パラメータ、リクエストボディで識別子（多くの場合、数値または予測可能な文字列）を使用しているように見えるAPIエンドポイントを特定します。これは多くの場合、正規のアプリケーショントラフィックやAPIドキュメント（OpenAPI/Swagger仕様など）を分析することで行われます。
認証: 低権限のユーザーアカウントの有効な認証情報を取得します。
操作: 特定した識別子をAPIリクエスト内で系統的に変更します。数値を増減させたり、一般的なパターンを試したり、他のコンテキストから既知のIDを置き換えたりします。
分析: APIレスポンスを調べます。操作した識別子を含むリクエストが他のユーザーのリソースに関連するデータを返したり、操作の成功を確認できたりした場合、IDORの脆弱性が存在する可能性が高いです。

Aikido SecurityのAIペネトレーションテストによるIDORの検出

複雑なAPI全体を手動でIDORについてテストするのは煩雑でミスが起こりやすい作業です。ここでAikido AIペネトレーションテストの出番です。AikidoのAIペネトレーションテストは、APIエンドポイントのIDOR脆弱性を自動的に調査できます。

一般的な仕組みは以下の通りです。

APIの理解: Aikido AIは、提供されたスコープ、リポジトリ、その他提供されたドキュメントに基づいてAPIを分析します。
認証済みスキャン: IDORテストは、認証済みユーザーの視点から実行すると最も効果的です。Aikidoはテストユーザーとしてログインするための認証情報を必要とします。これによりそのユーザーとしてリクエストを行うことができます。
識別子の特定: Aikidoは、API仕様をインテリジェントに分析し、直接オブジェクト参照になり得るパラメータ（userId、orderId、id など）を特定します。
侵入の試行: Aikidoは提供された認証情報を使用して、特定したエンドポイントにリクエストを行います。その後、特定したパラメータを異なる値（設定されていれば他のテストユーザーに属する可能性のある値、または単に連番/一般的なIDを試すなど）で系統的に置き換えます。
レスポンス分析: Aikidoはこれらの変更されたリクエストへのレスポンスを調べます。（ログイン中のテストユーザーの権限に基づいて）取得すべきでないデータを取得した場合や、操作が不正に成功した場合、Aikidoは潜在的なIDORの脆弱性としてフラグを立てます。

検出の先へ: IDORの防止

AikidoはIDORの検出に優れていますが、防止にはセキュアコーディングの実践が必要です。

強力な認可の実装: これが最も重要な防御策です。識別子を通じてリソースにアクセスするすべてのリクエストについて、現在認証されているユーザーがその特定のリソースにアクセスまたは変更するために必要な権限を持っているかをサーバー側で検証してください。クライアントから提供されたIDのみに依存しないでください。
直接的で推測可能なIDを避ける: 可能であれば、連番の整数（1、2、3）ではなく、UUID（Universally Unique Identifier）のような予測しにくい識別子を使用してください。ただし、UUIDを使用していても、UUIDが漏洩したり発見されたりする可能性があるため、認可チェック（ステップ1）は依然として必須であることを忘れないでください。
間接参照（マッピング）の使用: セッションベースの参照を使用するか、内部IDをユーザーごと/セッションごとの一時的なIDにマッピングすることを検討してください。これにより抽象化の層が追加されます。この場合も、サーバー側の認可は依然として不可欠です。