> For the complete documentation index, see [llms.txt](https://help.aikido.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aikido.dev/docs/docs-ja/penetorshontesuto/coverage-and-findings/what-issues-can-aikido-pentest-find/understanding-and-detecting-idor-vulnerabilities.md).
# IDOR 脆弱性の検出
APIは現代のアプリケーションをつなぐ接着剤であり、シームレスなデータ交換と機能提供を可能にします。しかし、この接続性は同時に潜在的なセキュリティリスクももたらします。APIで見つかる最も一般的かつ潜在的に深刻な脆弱性の一つが **Insecure Direct Object Reference（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を悪用する方法
攻撃者は、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にマッピングする方法を検討してください。これにより抽象化の層が追加されます。繰り返しになりますが、サーバー側の認可は不可欠です。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.aikido.dev/docs/docs-ja/penetorshontesuto/coverage-and-findings/what-issues-can-aikido-pentest-find/understanding-and-detecting-idor-vulnerabilities.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.