Broken Object Level Authorization (BOLA) は、攻撃者がリクエスト内のオブジェクトIDを操作することで、本来アクセス権がないリソースにアクセスできるようになるアクセス制御の脆弱性です。この脆弱性は主にAPIで発生し、サーバーは通常、クライアントから送信されたオブジェクトIDに基づいてユーザーがアクセスできるオブジェクトを判断しますが、適切な権限チェックを行わないことが多いです。
オンラインバンキングアプリを想像してみましょう。ユーザーは自分のアカウント情報を確認するために、次のようにリクエストを行うかもしれません： GET /account/12345。しかし、アプリがそのユーザーにそのアカウントを見る権限があるかどうかを確認しない場合、問題が生じる可能性があります。悪意のある人がリクエストを変更して他の誰かのアカウントを見ようとするかもしれません。たとえば、GET /account/67890 と試みるかもしれません。バンキングアプリは、各ユーザーが自分のアカウント情報のみを表示できるようにする必要があります。そうしないと、情報漏洩につながる可能性があります。
最新のOWASP Top 10では、Broken Access Control（BOLA）は2017年の5位から2021年には1位に上昇し、最も重要なウェブアプリケーションセキュリティリスクとなっています。この脆弱性は、ユーザーが意図した権限を超えたアクションを実行できる場合に発生し、無許可の情報開示、変更、またはデータ破損を引き起こす可能性があります。
BOLA脆弱性によって引き起こされる一般的な問題は何ですか？
BOLA脆弱性から生じる可能性のある問題には以下が含まれます：
- データ漏洩：攻撃者は他のユーザーのデータにアクセスできます。例えば、攻撃者は患者IDを変更することで、医療アプリケーション内の他の患者の医療記録にアクセスするかもしれません。
- アカウント乗っ取り：一部のケースでは、オブジェクトへの無許可のアクセスが全体のアカウントの乗っ取りにつながる可能性があります。例えば、攻撃者が車両識別番号（VIN）を変更することで、自分のものでない車両にアクセスし、制御するかもしれません。
- データ損失または破損：BOLA脆弱性は、データの変更や削除を引き起こす可能性もあります。例えば、攻撃者はドキュメントIDを変更することで、クラウドストレージサービス内の他のユーザーの文書を削除するかもしれません。
- ビジネスプロセスの混乱：eコマースプラットフォームでは、攻撃者が店舗名を操作して数千のオンラインストアの販売データにアクセスし、正常な業務運営を混乱させる可能性があります。
- 運用コストの増加：攻撃者はBOLA脆弱性を利用してサービス拒否攻撃を行い、大量の無許可リクエストでAPIリソースを消費し、サービス提供者にとってコストを増加させるかもしれません。
BOLA脆弱性攻撃の原則は何ですか？
BOLA脆弱性が発生する理由：
- APIエンドポイントがオブジェクトIDを受け取る：APIエンドポイントはオブジェクトのIDを受け取り、それはURI、リクエストヘッダー、またはリクエストボディを通じて渡されることがあります。APIがそのリソースにアクセスするための呼び出し元の権限を確認しない場合、BOLA脆弱性が存在する可能性があります。
- 適切な権限チェックの欠如：APIは、ログインユーザーが要求されたオブジェクトに対して操作を実行する権利があるかどうかを確認しないまま、要求された操作を実行する場合があります。これは、サーバーコンポーネントがクライアントの状態を完全に追跡せず、クライアントから送信されたオブジェクトIDなどのパラメータに依存してどのオブジェクトにアクセスできるかを決定する場合に多く見られます。
- 悪用の容易さ：攻撃者がBOLA脆弱性を特定すると、それを簡単なスクリプトを使用して悪用するのはしばしば容易です。攻撃者は、自分自身のリソースIDを他のユーザーのリソースIDに置き換えるだけで済みます。
- 機密情報の漏洩を引き起こす：BOLA脆弱性は、無許可の第三者に対して機密情報が開示される結果を招く可能性があり、データの損失や改ざんを引き起こす可能性もあります。場合によっては、オブジェクトへの無許可のアクセスが全体のアカウントの乗っ取りにつながることもあります。
要約すると、包括的なユーザー認証とパラメータの暗号化の欠如が、特定のユーザーがループホールを悪用し、アクセス権限を恣意的に変更できるようにします。以下の図は、ユーザーAがリソースAにのみアクセスできることを示しています。プログラムの認証が不完全な場合、ユーザーはAPIを構築してリソースBにアクセスできる可能性があり、その結果、リソースBにアクセスし、さらには修正することができます。
BOLA脆弱性を防ぐ方法は？
BOLA脆弱性を防ぐための主要な対策は以下の通りです。これらの予防措置を実施することで、BOLA脆弱性のリスクを大幅に減少させ、APIを無許可のアクセスや操作から保護できます。
| No. | 予防措置 | 説明 |
|---|---|---|
| 1 | オブジェクトレベルの認可チェックを実装する | 各APIエンドポイントでアクションを実行する前に、ユーザーが特定のオブジェクトに対して操作する権限があるかどうかを確認します。 |
| 2 | ランダムで予測不可能なIDを使用する | 連続整数や簡単に推測できるIDの使用を避け、攻撃者がリソース識別子を予測または操作する可能性を減少させます。 |
| 3 | 自動API作成の制限 | 自動的にAPIエンドポイントを生成するツールの使用を避け、各エンドポイントがアクセス制御モデルに従うことを確認します。 |
| 4 | APIエンドポイントの追跡と管理 | 定期的にセキュリティ監査やペネトレーションテストを実施し、潜在的なセキュリティ脆弱性を特定し修正します。 |
| 5 | APIゲートウェイの使用 | すべてのAPIリクエストの単一のエントリーポイントとしてAPIゲートウェイを設置し、セキュリティポリシーを適用します。 |
| 6 | 強力な認証と認可の実装 | OAuth 2.0、JWTなどの業界標準の認証プロトコルを使用し、役割ベースのアクセス制御を実装します。 |
| 7 | Webアプリケーションファイアウォール（WAF）の使用 | WAFは、企業APIに対する一般的なウェブアプリケーション攻撃に対して追加の保護層を提供します。 |
| 8 | データ検証 | サーバーが受け入れるすべてのコンテンツをフィルタリングし、XMLまたはJSONスキーマを使用してパラメータを検証します。 |
| 9 | レート制限 | 特定の時間枠内で、ユーザーまたはIPアドレスが行えるリクエストの数を制限し、ブルートフォースおよびDoS攻撃を防ぎます。 |
| 10 | セキュリティテスト | 定期的にAPIセキュリティテストを実施し、ペネトレーションテスト、インジェクションテスト、ユーザー認証テストを行い、脆弱性を特定し対処します。 |
| 11 | 監視とパッチ適用 | APIの異常なネットワーク活動を定期的に監視し、最新のセキュリティパッチ、バグ修正、新機能を使ってAPIを更新します。 |
| 12 | 機密データの暗号化 | SSL/TLS暗号化プロトコルを使用してAPIとクライアントアプリケーション間の通信を保護し、保存された機密データを暗号化します。 |
| 13 | アクセス制御リスト（ACL） | 特定のリソースへのユーザーアクセスを制御するためにACLを使用します。 |
| 14 | 最小権限の原則 | ユーザーがタスクを完了するために必要な最小限の権限のみを持つようにし、過剰な権限を避けます。 |
| 15 | 教育と訓練 | 開発者向けにセキュリティ意識向上のトレーニングを提供し、安全にAPIを設計・実装する方法を理解させます。 |
結論
BOLAは一般的なセキュリティの欠陥であり、機密データの漏洩や無許可の行動につながる可能性があります。アプリを設計・構築する際、開発者はすべてのオブジェクトへのアクセスを適切に制御する必要があります。この種の問題を防ぐために、開発やテスト中により多くの努力を注ぐ必要があります。もう一つの選択肢は、これらの懸念に対処するために強力なサードパーティソリューションを選択することです。
Tencent EdgeOneは、様々な脅威を効果的に遮断する堅牢なウェブ攻撃保護を提供します。広範な攻撃シグネチャデータベースを持ち、ウェブ攻撃、エクスプロイト、トロイの木馬、バックドア、およびその他のセキュリティ問題のリスクを減少させることができます。現在、無料トライアルを開始しており、登録またはお問い合わせいただければと思います。
よくある質問
Q1: BOLAはIDORにどのように関連していますか？
A1: BOLAはIDOR（Insecure Direct Object References）と密接に関連しています。基本的には、攻撃者が十分な認可チェックなしに他のユーザーに属するオブジェクトにアクセスまたは操作できる同じタイプの脆弱性を指します。
Q2: なぜBOLAは重大なセキュリティリスクと見なされていますか？
A2: BOLAはOWASP API Top 10リストで第1位にランク付けされています。APIで最も普及している脆弱性の一つであり、機密データを露出させたり、ユーザー情報への無許可アクセスを許可したりする可能性があります。
Q3: BOLA脆弱性の悪用の例を教えてください。
A3: PelotonのセキュリティインシデントはBOLAの悪用の一例です。攻撃者は、不十分なオブジェクトレベルの認可により、他のユーザーのプライベート情報を含むすべてのデータを見ることができました。
Q4: 開発者はBOLA脆弱性をどのように防ぐことができますか？
A4: BOLA脆弱性を防ぐために、開発者は適切なオブジェクトレベルの認可チェックを実装する必要があります。これには、各オブジェクトアクセスリクエストに対するユーザー権限の検証が含まれ、ユーザーがアクセスまたは修正を許可されているオブジェクトのみをアクセスできるようにします。