> 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/pentesuto/coverage-and-findings/what-issues-can-aikido-pentest-find/understanding-and-detecting-idor-vulnerabilities.md).
# 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を悪用する方法
攻撃者は、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は *検出する* IDORの検出に優れていますが、防止には安全なコーディング手法が必要です：
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/pentesuto/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.