OWASP Top 10 APIセキュリティリスク：壊れたオブジェクトレベル認可
2023年4月12日、Paul Dughi
2023年のリストはまだ確定していませんが、Open Worldwide Application Security Project® (OWASP) のGithubサイトでは、API セキュリティリスク TOP 10 をすべて確認し、コメントすることができます。リストのNo.1リスクは、壊れたオブジェクトレベル認可（BOLA、broken object level authorization）です。
BOLA は、脅威アクターが本来ならば制限されるべきデータオブジェクトのリクエストに成功した場合に発生します。
攻撃ベクトル
攻撃者は、リクエストに含まれるオブジェクトのIDを操作してAPI エンドポイントを悪用し、API を騙して機密データや保護データを返させます。BOLA は、サーバーコンポーネントがクライアントの状態を完全に把握しておらず、どのオブジェクトにアクセスすべきかをオブジェクト ID に依存しているようなアプリケーションで発生する可能性があります。
OWASPは、ハッカーによって容易に悪用されることを意味する悪用可能性スコアを 2 点としました。
セキュリティの弱点
OWASPによると、これは API に対する最も一般的かつインパクトの大きな攻撃の１つです。
アプリケーションが認可をチェックする適切なインフラストラクチャを実装していても、開発者がそのチェックを使用することを忘れて機密性の高いオブジェクトへのアクセスを許可してしまうことがあります。アクセス制御の検出は、自動化された静的テストや動的テストに必ずしも反応しないため、欠陥が検出されないことがあります。
OWASPもBOLAを普及度の点で３点としています。このセキュリティ脅威は、さまざまなドメインやアプリで見受けられます。
ビジネスへのインパクト
機密データへの不正アクセスは常に、暴露と責任のリスクを伴います。また、あるオブジェクトへの不正アクセスから、アカウントの乗っ取りなど、さらなる侵害へつながっていく可能性があります。
BOLAエクスプロイトは、以下のようなインシデントを引き起こす可能性があります。
- 機密記録の大規模な流出
- 閲覧、修正、削除を含む記録の操作
- 特権のエスカレーション
- 管理者アカウントのフルテイクオーバー
BOLA 攻撃の仕組み
攻撃者は、リクエストのコードにパターンを使っているシステムを探ります。たとえば、ユーザー ID やオブジェクト ID を変更し、API がどのように応答するかを確認することで、BOLAの欠陥を探り当てます。こうして見つかった欠陥からアクセスされると、適切なセキュリティプロトコルが導入されていないAPI は大きなリスクにさらされます。脅威アクターが API を通じてアクセスすると、すべてのデータが危険にさらされるのです。
実際にどのようなシナリオが想定されるかを説明しましょう。ある人が、顧客 ID を使用して合法的または非合法的に企業のシステムにアクセスしたとします。アクセスがいったん認証されると、その人のアイデンティティはトークンで表現されます。API リクエストでアクセスに使用した顧客 ID をほかのユーザーの ID に置き換えて、ほかのユーザーの個人情報にアクセスします。
これがうまくいくことを確認した攻撃者は、その後のリクエストで顧客 ID 番号を代用するプロセスを自動化し、さらに記録を流出させられます。
たとえば金融機関への侵入には、クレデンシャルスタッフィング攻撃が使われるかもしれません。リクエストの識別子を変更することで、攻撃者は異なるユーザーアカウントにアクセスでき、送金やデータのリダイレクトを異なるエンドポイントに行うこともできるかもしれません。
OWASPは、自動車メーカーが、車両の車体番号を用いてドライバーの携帯電話から API 経由で車両のリモートコントロールを可能にした例を挙げています。脅威者は理論上、デバイスを認証し、オンラインまたは車両本体で容易に入手できる別の車両の車体番号をすり替えることができます。実際の所有者の認証ではないことを API が検出できなければ、攻撃者は車両へのアクセスや始動、窃盗を行うことができるかもしれません。
実社会における例
このような侵害が、2018年に約230万人の加入者に影響を与えたT-Mobileの顧客データ漏洩の原因とされています。また、別のAPIベースの攻撃でも、2023年に3700万人のT-Mobileユーザーに影響が及んだ可能性があります。
Facebook および Parler に属するソーシャルメディアプラットフォームの API にも脆弱性が発見されました。Facebook の場合、これらの脆弱性により、攻撃者がほかのユーザーのページ上に投稿を作成することが可能になりました。この投稿はニュースフィードには表示されないものの、リンクを通じてアクセスできたのです。
Parler の場合は、認証なしで公開された投稿に API アクセスすることができました。Parler の投稿 ID は連番であったため、攻撃者は ID 番号を簡単に代用できました。レート制限がないため、自動化により極めて高いレートでデータを抽出することができたのです。
BOLAの脆弱性を検出する
OWASPは、BOLA の検出可能性を2点としています。API スキャンとテストは、BOLA 脆弱性を検出するためのベストプラクティスです。
検出は、API エンドポイントと識別子の評価から始まります。エンジニアは、API のライフサイクルにわたってオブジェクト ID をテストできます。たとえば、オブジェクト ID の置き換えを要求するテストケースを作成し、エラーメッセージを探すことができます。エラーメッセージが返されない場合は、潜在的な暴露を示す可能性があります。また、オブジェクトの読み取り、書き込み、削除の動作をテストすることも可能です。自動テストと手動による侵入テストの組み合わせは、BOLA の欠陥を発見するのに役立ちます。
残念ながら、API ゲートウェイや Web アプリケーションファイアウォールといった従来のツールでは、BOLA 攻撃からの防御はたいていできません。API ゲートウェイは、認証を管理するのには適していますが、悪意のあるリクエストを発見することはできません。ほとんどの場合、これらのツールは検出のためにシグネチャを使用し、未知のケースを調査することはないのです。
また BOLA 攻撃は、ID を変更しただけの通常の API リクエストと同じように見えることがあります。システムは、実際に悪用された後にしか、通常と異なる点に気づけないかもしれません。
セキュリティチームは、大量の失敗した API リクエスト、特に認証エラーが発生した API リクエストに注意を払う必要があります。攻撃者が有効なオブジェクト ID を探す際、不正な（401）、見つからない（404）、または禁止されている（403）エラーが発生することが少なくありません。また、同じ認証トークンからオブジェクト ID を複数回リクエストすることも、悪意のある行為を示す場合があります。
BOLAの脆弱性を防止する
OWASPは、BOLA脆弱性の予防に役立ついくつかの具体的な戦略を提示しています。
- ユーザーポリシーと階層に依存する適切な認可メカニズムの実装
- レコードのオブジェクト ID やグローバル一意識別子（GUID）のランダム化
- ログインしたユーザーが、レコードに対して要求されたアクションを実行する権限を持っているかどうかをチェックするための権限付与メカニズム
- 認証メカニズムを評価するためのアクティブテスト
BOLAはだいぶ前から知られているエクスプロイトです。10年以上前、AT&T を通じて Apple の iPad の API 侵害が発生し、政府やメディアの高官を含む約10万人のユーザーの電子メールが流出したことがあります。にもかかわらず、壊れたオブジェクトレベル認可は今なお、API セキュリティの脅威リストの上位に位置しています。
原文はこちら
OWASP Top 10 API security risks: Broken object level authorization
Apr. 12, 2023 Paul Dughi
https://blog.barracuda.com/2023/04/12/owasp-top-10-api-broken-object-level-authentication/
