> 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/penetosuto/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はアプリケーションが内部オブジェクト（データベースレコード、ファイル、ユーザープロファイルなど）へ直接アクセスするための識別子を使用している一方で、 **適切な認可チェックを行わず** に、 *現在のユーザー* が実際にアクセスする権限を *その特定のオブジェクトに対して*.
持っていることを確認していない場合に発生します。
* 「識別子」は、多くの場合、ユーザー/クライアントから提供されるもので、たとえば次のようなものです。`/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. **リクエストを送れるようになります。** 識別子の特定: `userId`, `orderId`, `id`など）のような、直接オブジェクト参照の可能性があるパラメータを特定するために、AikidoはAPI仕様をインテリジェントに分析します。
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/penetosuto/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.