オープン・ワールドワイド・アプリケーションセキュリティプロジェクト

API5:2023 Broken Function Level Authorization

脅威要因 / 攻撃ベクトル セキュリティ弱点 影響
API固有:悪用可能性 容易 普及度 一般的:検出可能性 容易 技術的 深刻:特定のビジネスに依存
攻撃者は、匿名ユーザーまたは通常の権限を持つユーザーとしてアクセスするべきでないAPIエンドポイントに対して正当なAPIコールを送信する必要があります。公開されたエンドポイントは簡単に悪用されます。 関数またはリソースの認可チェックは、通常、構成またはコードレベルで管理されます。適切なチェックの実装は、現代のアプリケーションには多種多様な役割、グループ、複雑なユーザー階層(サブユーザー、複数の役割を持つユーザーなど)が含まれるため、混乱のもとになる場合があります。APIは構造化されており、異なる機能にアクセスすることが予測しやすいため、これらの欠陥を発見することが容易です。 このような欠陥により、攻撃者は認可されていない機能にアクセスできるようになります。管理機能はこの種の攻撃の主要なターゲットであり、データの開示、データの損失、またはデータの破損につながる可能性があります。最終的にはサービスの中断につながる可能性があります。

APIは脆弱ですか?

壊れた関数レベルの認可問題を見つけるための最良の方法は、認可メカニズムの徹底した分析を行うことです。ユーザー階層、アプリケーション内の異なる役割やグループを考慮しながら、次のような質問をします:

  • 通常のユーザーは管理エンドポイントにアクセスできますか?
  • ユーザーはHTTPメソッドを単純に変更することで、アクセスすべきでない機敏なアクション(例:作成、変更、削除)を実行できますか?
  • グループXのユーザーは、単にエンドポイントURLとパラメータを推測することでグループYのユーザーにのみ公開されるべき機能にアクセスできますか(例:/api/v1/users/export_all)?

APIエンドポイントがURLパスに基づいて通常または管理者専用であると仮定しないでください。

開発者が通常、管理エンドポイントのほとんどを特定の相対パス(例:/api/admins)の下に公開することを選択する一方で、これらの管理エンドポイントが通常のエンドポイントと一緒に他の相対パス(例:/api/users)に存在することが非常に一般的です。

攻撃シナリオの例

シナリオ #1

招待されたユーザーのみが参加できるアプリケーションの登録プロセス中、モバイルアプリケーションはAPIコールをトリガーしてGET /api/invites/{invite_guid}にアクセスします。レスポンスには、招待の詳細(ユーザーの役割とメールアドレスを含む)が含まれています。

攻撃者はこのリクエストを複製し、HTTPメソッドとエンドポイントを操作してPOST /api/invites/newにアクセスします。このエンドポイントは管理コンソールを使用してのみアクセスすべきですが、関数レベルの認可チェックが実装されていません。

攻撃者は問題を悪用し、管理者権限で新しい招待を送信します:

POST /api/invites/new

{
  "email": "[email protected]",
  "role":"admin"
}

その後、攻撃者は悪意のある招待を使用して自分自身に管理者アカウントを作成し、システムへの完全なアクセスを獲得します。

シナリオ #2

特定のエンドポイントGET /api/admin/v1/users/allは、管理者専用に公開されるべきですが、関数レベルの認可チェックが実装されていません。API構造を学んだ攻撃者は、このエンドポイントにアクセスし、アプリケーションのユーザーの機密情報を公開します。

予防方法

アプリケーションには、ビジネス機能から呼び出される一貫性のある、分析しやすい認可モジュールが必要です。このような保護は通常、アプリケーションコード以外の1つ以上のコンポーネントによって提供されます。

  • 強制メカニズムはすべてデフォルトでアクセスを拒否し、特定の役割に対する明示的な許可を必要とします。
  • ビジネスロジックとグループの階層を考慮しながら、APIエンドポイントを関数レベルの認可欠陥に対してレビューします。
  • すべての管理コントローラーが管理抽象コントローラーから継承し、ユーザーのグループ/役割に基づいて認可チェックを実装することを確認します。
  • 通常のコントローラー内の管理機能が、ユーザーのグループと役割に基づいて認可チェックを実装することを確認します。

参考文献

OWASP

外部