# IDOR脆弱性の検出
APIは現代のアプリケーションをつなぐ接着組織であり、シームレスなデータ交換と機能提供を可能にします。しかし、この接続性は潜在的なセキュリティリスクももたらします。APIで見つかる最も一般的で、かつ最も損害の大きい脆弱性の一つが **安全でない直接オブジェクト参照（IDOR）**。OWASP Top 10に頻繁に挙げられるIDORを理解し、軽減することは、アプリケーションとユーザーデータを守るうえで重要です。
この記事では、IDORとは何か、攻撃者がAPIでどのようにそれを悪用するのか、そしてAikido SecurityのAIペンテスト機能を活用して事前に検出する方法を解説します。
### IDORとは正確には何ですか？
アパートの建物に住んでいるところを想像してください。あなたの鍵（認証）で正面玄関に入り、 *自分の* アパート（例：#101）に行けます。IDOR脆弱性とは、アパート番号（#102など）を知っているだけで *その* ドアを開けられてしまうような仕組みのようなものです。あなたの鍵は#101用にしかないにもかかわらず。
技術的には、IDORは、アプリケーションが内部オブジェクト（データベースレコード、ファイル、ユーザープロフィールなど）への直接アクセスに識別子を使用する一方で、 **適切な認可チェックを実行せず** 、 *現在のユーザー* が実際にアクセスを許可されていることを確認していない *その特定のオブジェクト*.
「識別子」は、多くの場合、ユーザー/クライアントから提供される次のようなものです：
* URLパス内のユーザーID（`/api/users/12345`)
* クエリパラメータ内の注文ID（`/api/orders?id=9876`)
* リクエスト本文内のドキュメントID（`{"documentId": "abc-def"}`)
脆弱性は識別子そのものの使用ではなく、 *検証の欠如* 、つまりログイン中のユーザーがその識別子が指し示すリソースにアクセスする権限を持っていることの確認がない点にあります。
### なぜIDORは危険なのか、特にAPIでは？
APIは多くの場合、アプリケーションの中核機能とデータを公開します。APIのIDOR脆弱性は次のような事態につながる可能性があります：
1. **データ漏えい：** 攻撃者は識別子を順に試すことで（例：変更しながら `/api/users/101` を `/api/users/102`, `/api/users/103`などへ）、他のユーザーに属する機密情報（個人情報、財務データ、非公開メッセージ）にアクセスできます。
2. **不正な操作：** 攻撃者は、PUT、POST、DELETEリクエスト内の識別子を操作することで、他者に属するデータを変更または削除できる場合があります（例： `/api/orders/555` を `/api/orders/556` を削除リクエストで変更する）。
3. **権限昇格：** 場合によっては、別のユーザーのデータや設定にアクセスすることが間接的により高い権限を与えることがあります。
4. **ビジネスロジックの欠陥：** IDORは、請求書、レポート、システム設定などのリソースに不正に相互作用できるようにすることで、業務プロセスを混乱させる可能性があります。
### APIスキャンによるIDORの悪用方法
攻撃者はしばしば、自動化ツールや簡単なスクリプトを使ってAPIを調査し、IDOR脆弱性を探します。一般的な手順は次のとおりです：
1. **発見：** パス、パラメータ、またはリクエスト本文で識別子を使っているように見えるAPIエンドポイントを特定します（多くの場合、数値や予測可能な文字列）。これは、正当なアプリケーション通信やAPIドキュメント（OpenAPI/Swagger仕様など）を分析することで行われます。
2. **認証：** 権限の低いユーザーアカウントの有効な認証情報を取得すること。
3. **操作：** APIリクエスト内で特定した識別子を体系的に変更します。数値を増減させたり、一般的なパターンを試したり、他の文脈から知られているIDを置き換えたりします。
4. **分析：** APIレスポンスを調べます。識別子を改変したリクエストがデータを返したり、 *他のユーザーの* リソースに関連するアクションを確認したりする場合、IDOR脆弱性が存在する可能性が高いです。
### Aikido SecurityのAIペンテストでIDORを検出する
複雑なAPI全体でIDORを手動テストするのは手間がかかり、ミスも起こりやすいです。そこでAikidoのAIペンテストが役立ちます。AikidoのAIペンテストは、APIエンドポイントを自動的に調査し、IDOR脆弱性を検出できます。
一般的には次のように動作します：
1. **APIを理解する：** Aikido AIは、提供されたスコープ、リポジトリ、その他あなたが提供する文書に基づいてAPIを分析します。
2. **認証済みスキャン：** IDORテストは、認証済みユーザーの視点から実施すると最も効果的です。Aikidoはテストユーザーとしてログインするための認証情報を必要とします。これにより、 *そのユーザーとして*.
3. **識別子の特定：** AikidoはAPI仕様をインテリジェントに解析し、直接オブジェクト参照の可能性があるパラメータ（ `userId`, `orderId`, `id`など）を特定します。
4. **侵入試行：** Aikidoは提供された認証情報を使って特定されたエンドポイントにリクエストを送信します。次に、特定されたパラメータを異なる値に体系的に置き換えます（例： *他の* 設定されていれば他のテストユーザーに属する値、あるいは単純に連番/一般的なIDを試す）。
5. **レスポンス分析：** Aikidoはこれらの変更されたリクエストへのレスポンスを調べます。ログイン中のテストユーザーの権限に基づいて受け取るべきでないデータを受け取った場合、またはアクションが不適切に成功した場合は、潜在的なIDOR脆弱性としてフラグを立てます。
### 検出を超えて：IDORを防ぐ
Aikidoは *検出* に優れていますが、予防には安全なコーディング手法が必要です：
1. **強力な認可を実装する：** これは最も重要な防御です。 *あらゆる* 識別子を介してリソースにアクセスするリクエストごとに、サーバー側で *現在認証されているユーザー* がアクセスまたは変更するために必要な権限を持っていることを確認してください *その特定のリソース*。クライアントから提供されたIDだけに依存しないでください。
2. **直接的で推測しやすいIDを避ける：** 可能であれば、連番の整数（`1`, `2`, `3`）の代わりにUUID（Universally Unique Identifier、汎用一意識別子）のような予測しにくい識別子を使用してください。ただし、UUIDを使っていても認可チェック（ステップ1）は依然として必須であることを忘れないでください。UUIDも漏えいしたり発見されたりする可能性があるためです。
3. **間接参照（マッピング）を使う：** セッションベースの参照を使用するか、内部IDをユーザーごと/セッションごとの一時IDにマッピングすることを検討してください。これにより抽象化の層が追加されます。とはいえ、サーバー側の認可は引き続き不可欠です。