壊れたオブジェクトレベルの認可｜サイバーセキュリティ.com

  1. ホーム /
  2. セキュリティ用語集 /
  3. 壊れたオブジェクトレベルの認可
             

壊れたオブジェクトレベルの認可

壊れたオブジェクトレベルの認可（Broken Object Level Authorization：BOLA）とは、アプリケーションやAPIがオブジェクトへのアクセス権を適切に検証できていないために、権限を持たないユーザーが他のユーザーのリソースにアクセスできてしまう脆弱性を指します。この脆弱性が発生すると、攻撃者は自分以外のユーザーのデータや機密情報を不正に閲覧、変更、削除できるようになります。

特に、APIを使用しているシステムでは、IDやパラメータの管理が不適切な場合に、この脆弱性が生じやすく、Webアプリケーションやモバイルアプリケーションでよく見られる問題です。壊れたオブジェクトレベルの認可は、OWASP API Security Top 10の中でも最も重大な脆弱性の一つとされています。

壊れたオブジェクトレベルの認可の仕組み

壊れたオブジェクトレベルの認可は、次のような流れで発生します：

  1. リクエストパラメータによるリソース識別
    アプリケーションは、ユーザーがアクセスするリソースを、IDなどのリクエストパラメータを用いて識別します。例えば、ユーザーIDやリソースIDをURLやパラメータとして指定するケースです。
  2. アクセス権の不十分なチェック
    アプリケーションがIDやパラメータを基にリソースへのアクセスを許可する際に、アクセスが許可されたユーザーがリソースの所有者であるか、またはアクセス権限を持っているかを十分に確認していない場合、権限を持たないユーザーが他のユーザーのリソースにアクセスできてしまいます。
  3. 不正アクセスの発生
    攻撃者は自分のIDやリソースIDを他のIDに置き換えることで、他のユーザーのリソースにアクセスできてしまいます。これにより、他のユーザーの個人情報や機密データの閲覧や改ざんが可能となります。

壊れたオブジェクトレベルの認可の例

壊れたオブジェクトレベルの認可は、以下のような状況で発生することがあります：

  • ユーザープロファイルの不正アクセス
    例えば、https://example.com/api/user/123というエンドポイントでユーザープロファイルを取得する際に、攻撃者が自分のID（123）を他のユーザーのID（456）に置き換えることで、他人のプロファイル情報を不正に閲覧できてしまうケースです。
  • 購入履歴や注文履歴の閲覧
    オンラインショッピングサイトなどで、注文情報を取得するAPIがユーザーIDの検証を行わずに、https://example.com/api/order/456といったURLにアクセスできる場合、他人の購入履歴や注文内容を確認できてしまいます。
  • ソーシャルメディアの投稿操作
    ソーシャルメディアなどで、投稿の編集や削除にリソースIDが使われている場合、攻撃者が他人の投稿IDを指定して編集や削除を試みることができます。

壊れたオブジェクトレベルの認可のリスクと影響

壊れたオブジェクトレベルの認可が発生すると、以下のような重大なリスクや影響があります：

  1. データ漏洩
    攻撃者が他人の個人情報、購入履歴、アカウント情報などの機密データにアクセスできるため、情報漏洩のリスクが高まります。特に、個人情報や医療情報などが流出すると、法的な責任が発生する場合もあります。
  2. データの改ざんや削除
    攻撃者が他のユーザーのリソースを操作できる場合、データの改ざんや削除が行われ、システムの信頼性が損なわれます。さらに、データ改ざんが進行すると、ビジネスの信頼性も低下する恐れがあります。
  3. 不正アクセスによる金銭的被害
    攻撃者が他のユーザーのアカウントに不正アクセスして支払情報や注文内容を変更することで、金銭的な被害が発生することがあります。
  4. 企業イメージや信頼性の低下
    情報漏洩やデータの改ざんが発覚すると、企業の信頼性やイメージが損なわれ、顧客離れが進む可能性もあります。

壊れたオブジェクトレベルの認可に対する対策

壊れたオブジェクトレベルの認可を防止するためには、次のような対策が効果的です。

  1. ユーザーごとのアクセス権の明確化
    すべてのAPIエンドポイントで、リソースにアクセスしようとするユーザーが正当なアクセス権を持っているかを検証します。たとえば、ユーザーIDやロールに基づいたアクセス制御を行い、アクセス可能なリソースを限定します。
  2. サーバーサイドでのアクセス権確認
    クライアントから送信されるリクエストに頼るのではなく、サーバーサイドでアクセス権を管理し、リソースごとに所有者や権限を確認することが重要です。クライアント側での検証は回避される可能性があるため、サーバー側でのチェックが必須です。
  3. IDの推測防止
    APIに渡されるIDを連続番号や予測しやすい形式ではなく、UUIDなどのランダムで一意な形式にすることで、他のIDを推測しにくくします。これにより、攻撃者が他のリソースにアクセスする可能性が低下します。
  4. アクセス制御の設計とテスト
    アプリケーションの開発段階で、セキュアなアクセス制御モデルを設計し、アクセス制御に関するテスト（たとえばペネトレーションテスト）を行い、潜在的な脆弱性を特定して修正します。
  5. セキュリティガイドラインの遵守
    OWASPのガイドラインなど、セキュリティベストプラクティスに従ってアクセス制御を実装し、特に壊れたオブジェクトレベルの認可への対策が十分に行われているか確認します。

まとめ

壊れたオブジェクトレベルの認可は、APIやアプリケーションで不正アクセスを防止するためにアクセス権を適切に管理できていない場合に発生する脆弱性です。攻撃者は、この脆弱性を利用して他のユーザーのデータにアクセスしたり、改ざんや削除を行ったりすることができ、情報漏洩や金銭的な損害につながる恐れがあります。これを防ぐためには、サーバーサイドでのアクセス権確認やIDの推測防止、適切なアクセス制御の設計・テストなどの対策が重要です。

関連コラム（あわせて、以下の記事もよく読まれています）

製品・サービス（当該コラムの内容に関連する製品・サービスはこちら）


SNSでもご購読できます。