Ctrlk
Changelog NotificationsAPIAikido login
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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にマッピングする方法を検討してください。これにより抽象化の層が追加されます。とはいえ、サーバー側の認可は引き続き不可欠です。

最終更新

役に立ちましたか？