API5:2023 機能レベル認可の不備 (Broken Function Level Authorization)

脅威エージェント/攻撃手法セキュリティ上の弱点影響

API 依存 : 悪用難易度 容易

普及度 普通 : 検出難易度 容易

技術的影響 重度 : ビジネス依存

悪用には攻撃者が匿名ユーザーや通常の非特権ユーザーとしてアクセスしないはずの API エンドポイントに正当な API コールを送信する必要があります。公開されているエンドポイントは容易に悪用されるでしょう。

機能やリソースに対する認可チェックは通常は設定やコードレベルで管理されます。最近のアプリケーションには多くの種類のロール、グループ、複雑なユーザー階層 (サブユーザーや複数のロール持つユーザーなど) を含むことがあるため、適切なチェックを実装するのは混乱を招く作業になるかもしれません。API はより構造化されており、さまざまな機能への予測可能であるため、API におけるこれらの欠陥を発見するのは簡単です。

このような欠陥があると、攻撃者は認可されていない機能にアクセスできます。この種の攻撃では管理機能が重要なターゲットとなり、データ開示、データ損失、データ破損につながる可能性があります。最終的に、サービスの中断につながる可能性があります。

その API は脆弱か？

機能レベル認可の不備の問題を見つける最良の方法はユーザー階層、アプリケーション内のさまざまなロールやグループを念頭に置きながら、認可メカニズムを深く解析し、以下の質問をすることです。

  • 一般ユーザーが管理エンドポイントにアクセスできますか？

  • ユーザーは単に HTTP メソッドを変更 (GET から DELETE へなど) するだけで、アクセスできないはずの機密性の高い操作 (作成、変更、削除など) を実行できますか？

  • グループ X のユーザーはエンドポイント URL とパラメータを推測するだけで、グループ Y のユーザーのみに公開されるべき機能 (/api/v1/users/export_all など) にアクセスできますか？

URL パスだけをベースとして API エンドポイントが通常か管理かを決めてはいけません。

開発者は /api/admins のような特定の相対パスでほとんどの管理エンドポイントを公開することを選択するかもしれませんが、 /api/users のような一般エンドポイントとともに他の相対パスで管理エンドポイントを見つけることはとてもよくあることです。

攻撃シナリオの例

シナリオ #1

招待されたユーザーのみが参加できるアプリケーションの登録プロセス中に、モバイルアプリケーションは GET /api/invites/{invite_guid} への API コールをトリガーします。 レスポンスにはユーザーのロールやユーザーの電子メールなど招待についての詳細が記された JSON が含まれています。

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

攻撃者はこの問題を悪用し、管理者権限を付与して新規招待を送信します。

POST /api/invites/new

{
  "email": "attacker@somehost.com",
  "role":"admin"
}

その後、攻撃者は悪意を持って作成された招待を使用して自分自身に管理者アカウントを作成し、システムへのフルアクセスを獲得します。

シナリオ #2

API には管理者のみに公開すべきエンドポイント GET /api/admin/v1/users/all があります。 このエンドポイントはアプリケーションのすべてのユーザーの詳細を返しますが、機能レベルの認可チェックを実装していません。 API の構造を突き止めた攻撃者は経験に基づいた推測でこのエンドポイントにアクセスすることに成功し、アプリケーションのユーザーの機密情報を暴露してしまいます。

防止方法

アプリケーションにはすべてのビジネス機能から呼び出されて一貫性があり解析が容易な認可モジュールを持つ必要があります。 多くの場合、このような保護はアプリケーションコードの外部にある一つまたは複数のコンポーネントによって提供されます。

  • 執行メカニズムはデフォルトですべてのアクセスを拒否し、すべての機能へのアクセスには特定のロールへの明示的な付与を必要とします。

  • アプリケーションのビジネスロジックとグループの階層を念頭に置きながら、API エンドポイントを機能レベルの認可の欠陥についてレビューします。

  • すべての管理コントローラがユーザーのグループやロールに基づく認可チェックを実装した管理抽象コントローラから継承していることを確認します。

  • 一般コントローラ内の管理機能にはユーザーのグループやロールに基づく認可チェックを実装していることを確認します。

参考資料

OWASP

その他

PreviousAPI4:2023 制限のないリソース消費 (Unrestricted Resource Consumption)NextAPI6:2023 機密性の高いビジネスフローへの制限のないアクセス (Unrestricted Access to Sensitive Business Flows)

Last updated