オブジェクトレベル認可の欠如（BOLA）
| 脅威エージェント/攻撃ベクトル | セキュリティの弱点 | 影響 |
|---|---|---|
| API特有：悪用の容易さ 簡単 | 普及度 広範：検出容易度 簡単 | 技術的影響 中程度：ビジネス特有 |
| 攻撃者は、リクエスト内で送信されるオブジェクトのIDを操作することで、オブジェクトレベル認可が欠如しているAPIエンドポイントを悪用できます。オブジェクトIDは連続した整数、UUID、または一般的な文字列など、何でもかまいません。データ型に関係なく、それらはリクエストターゲット（パスまたはクエリ文字列パラメータ）、リクエストヘッダ、またはリクエストペイロードの一部として簡単に識別できます。 | この問題は、サーバーコンポーネントが通常、クライアントの状態を完全に追跡せず、代わりにオブジェクトIDなどのクライアントから送信されるパラメータに依存してアクセスするオブジェクトを決定するため、APIベースのアプリケーションでは非常に一般的です。サーバーレスポンスは通常、リクエストが成功したかどうかを理解するのに十分です。 | 他のユーザーのオブジェクトへの不正アクセスにより、機密データの漏洩、データの損失、またはデータの改ざんが発生する可能性があります。特定の状況下では、オブジェクトへの不正アクセスがアカウント全体の乗っ取りに繋がることもあります。 |
APIは脆弱ですか？
オブジェクトレベル認可は、ユーザーがアクセス権を持つべきオブジェクトにのみアクセスできるように検証するために通常コードレベルで実装されるアクセス制御メカニズムです。
オブジェクトのIDを受け取り、オブジェクトに対してアクションを実行するすべてのAPIエンドポイントは、オブジェクトレベルの認可チェックを実装する必要があります。チェックは、ログインしているユーザーが要求されたオブジェクトに対して要求されたアクションを実行する権限を持っているかどうかを検証する必要があります。
このメカニズムの失敗は、通常、不正な情報開示、改ざん、またはデータの破壊につながります。
現在のセッションのユーザーIDを（例：JWTトークンから抽出して）脆弱なIDパラメータと比較することは、オブジェクトレベル認可の欠如（BOLA）を解決するのに十分ではありません。このアプローチは、ケースの一部を解決するだけです。
BOLAの場合、設計上、ユーザーは脆弱なAPIエンドポイント/機能にアクセスできます。違反はオブジェクトレベルで、IDを操作することによって発生します。攻撃者がアクセスしてはならないAPIエンドポイント/機能にアクセスできた場合、これはオブジェクトレベル認可の欠如ではなく、機能レベル認可の欠如（BFLA）のケースです。
攻撃シナリオの例
シナリオ #1
オンラインストア（ショップ）向けのeコマースプラットフォームが、ホストされているショップの収益チャートを表示するリストページを提供しています。ブラウザリクエストを調査すると、攻撃者はこれらのチャートのデータソースとして使用されるAPIエンドポイントとそのパターンを特定できます：/shops/{shopName}/revenue_data.json。別のAPIエンドポイントを使用して、攻撃者はすべてのホストされたショップ名のリストを取得できます。リスト内の名前を操作する簡単なスクリプトを使用して、URL内の{shopName}を置き換えることで、攻撃者は多数のeコマースストアの売上データにアクセスできます。
シナリオ #2
ある自動車メーカーは、モバイルAPIを介して運転者の携帯電話と通信することで、車両を遠隔操作できるようにしています。APIは、運転者が遠隔でエンジンを始動・停止したり、ドアをロック・アンロックしたりすることを可能にします。このフローの一環として、ユーザーはAPIに車両識別番号（VIN）を送信します。APIは、VINがログインしているユーザーに属する車両を表していることを検証しないため、BOLAの脆弱性が生じます。攻撃者は自分の所有していない車両にアクセスできます。
シナリオ #3
オンライン文書ストレージサービスは、ユーザーが文書を閲覧、編集、保存、および削除できるようにします。ユーザーの文書が削除されるとき、文書IDを含むGraphQLミューテーションがAPIに送信されます。
POST /graphql
{
"operationName":"deleteReports",
"variables":{
"reportKeys":["<DOCUMENT_ID>"]
},
"query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) {
{
deleteReports(reportKeys: $reportKeys)
}
}"
}
指定されたIDの文書は、さらなる権限チェックなしに削除されるため、ユーザーは他のユーザーの文書を削除できる可能性があります。
防止方法
- ユーザーポリシーと階層に基づいた適切な認可メカニズムを実装します。
- 認可メカニズムを使用して、ログインしているユーザーがデータベース内のレコードにアクセスするためにクライアントからの入力を使用するすべての関数で要求されたアクションを実行する権限を持っているかどうかを確認します。
- レコードIDとしてランダムで予測不可能な値をGUIDとして使用することを優先します。
- 認可メカニズムの脆弱性を評価するテストを作成します。テストが失敗する変更はデプロイしないでください。