API1:2023 オブジェクトレベル認可の不備 (Broken Object Level Authorization)

PreviousOWASP API セキュリティ Top 10 NextAPI2:2023 認証の不備 (Broken Authentication)

Last updated 2 years ago

API1:2023 オブジェクトレベル認可の不備 (Broken Object Level Authorization)

脅威エージェント/攻撃手法

セキュリティ上の弱点

影響

API 依存 : 悪用難易度容易

普及度広範 : 検出難易度容易

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

攻撃者はリクエスト内で送信されるオブジェクトの ID を操作することで、オブジェクトレベル認可に不備がある脆弱な API エンドポイントを悪用できます。オブジェクト ID には連続する整数、UUID、汎用文字列を使用できます。データ型に関わらず、リクエストターゲット (パスまたはクエリ文字列パラメータ)、リクエストヘッダ、リクエストペイロードの一部にあり、識別することは簡単です。

この問題は API ベースのアプリケーションにおいて非常に一般的です。なぜならサーバーコンポーネントは通常、クライアントの状態を完全には追跡せず、代わりにクライアントから送信されるオブジェクト ID などのパラメータに依存して、どのオブジェクトにアクセスするかを決定しているからです。リクエストが成功したかどうかは、通常、サーバーのレスポンスで十分に理解できます。

他のユーザーのオブジェクトへの不認可アクセスは不認可な第三者へのデータ開示、データ損失、データ操作につながる可能性があります。特定の状況下では、オブジェクトへの不認可アクセスはアカウントの完全な乗っ取りにつながる可能性もあります。

その API は脆弱か？

オブジェクトレベル認可は通常はコードレベルで実装されるアクセス制御メカニズムであり、ユーザーがアクセス許可を持つべきオブジェクトにのみアクセスできることを検証するものです。

オブジェクトの ID を受け取り、そのオブジェクトに対して何らかのアクションを実行するすべての API エンドポイントはオブジェクトレベル認可チェックを実装する必要があります。このチェックではログインしたユーザーがリクエストしたオブジェクトに対してリクエストしたアクションを実行する権限を持っていることを検証する必要があります。

このメカニズムの障害は一般的にすべてのデータの不認可な情報開示、改変、破壊につながります。

現在のセッションのユーザー ID を (JWT トークンから抽出するなどして) 脆弱な ID パラメーターと比較することはオブジェクトレベル認可の不備 (Broken Object Level Authorization, BOLA) を解決するための十分な解決策とは言えません。このアプローチではごく一部のケースにしか対処できません。

BOLA の場合には、ユーザーが脆弱な API エンドポイントや機能にアクセスすることは意図したものです。違反は ID を操作することによりオブジェクトレベルで発生します。攻撃者がアクセスすべきではない API エンドポイントや機能にアクセスできる場合、これは BOLA というより (BFLA) のケースとなります。

攻撃シナリオの例

シナリオ #1

オンラインストア (ショップ) 用の e コマースではホストされているショップの収益チャートがある一覧ページを提供します。ブラウザのリクエストを調べることで、攻撃者はこれらのチャートのデータソースとして使用されている API エンドポイントとそのパターン /shops/{shopName}/revenue_data.json を特定できます。他の API エンドポイントを使用することで、攻撃者はホストされているショップ名のリストを取得できます。そのリストの名前を操作する簡単なスクリプトで URL の {shopName} を置き換えることで、攻撃者は数千の e コマースストアの売上データにアクセスできます。

シナリオ #2

自動車製造業者は運転者のモバイルフォンと通信するモバイル API で車両の遠隔操作を可能にしました。この API で運転者は遠隔でエンジンの始動と停止やドアのロックとアンロックを行うことができます。このフローの一環として、ユーザーは車両識別番号 (Vehicle Identification Number, VIN) を API に送信します。

この 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 として使用することを推奨します。
認可メカニズムの脆弱性を評価するテストを作成します。テストが不合格となるような変更をデプロイしてはいけません。

参考資料

OWASP

その他