Broken Object Level Authorization (BOLA)

Broken Object Level Authorizationとは何か

Broken Object Level Authorisation (BOLA)は、すべてオブジェクトから始まる話です。オブジェクトとは、オブジェクト指向プログラミングの考え方における基本的な要素であり、プログラム設計の際に最初に検討する対象です。また、コードの単位としても扱われます。これはアカウント、請求書、クレジットノートなどあらゆるものが該当し、通常は個別に識別するためのIDが付与されています。しかし、そのオブジェクトにアクセスする許可があるかどうか、常に確認する必要があります。一見すると単純に思えますが、実際は複雑で、この点については後述の「テスト」セクションで詳しく説明します。

サーバーが、現在ログイン中の利用者やログアウト状態の利用者に、本来許可されていないオブジェクトの読み取り、更新、削除の権限があるかどうかを適切に確認しない場合に、このBroken Objectの問題が発生します。

Broken Object Level Authorizationの主な2種類

オブジェクトに関するBroken Object Level Authorizationには2種類があり、利用者IDがサーバーに渡される場合とオブジェクトIDが渡される場合に分かれます。ここでは両方について説明します。

利用者IDに基づく

利用者の全リソースを取得する際など、利用者IDがサーバーに渡されるケースがあります。例えば：

<https://google.com/get_users_search_history?userID=1234>

もし利用者IDを他の利用者のものに置き換えても、本来は他の利用者の検索履歴は取得できないはずですが、Broken Object Level Authorizationの問題が起こると、他の利用者の検索履歴が閲覧できてしまいます。

この問題は、開発者にとっては解決が容易です。現在ログイン中の利用者が、そのオブジェクトにアクセスできるかどうかを確認すればよいのです。この例では、GETパラメータの利用者IDとオブジェクトの所有者の利用者IDが一致しているかを確認する必要があります。

擬似コード:

if($_GET['userID'] === object.ownerID){
    ShowData()
} else {
    echo "このデータの閲覧は許可されていません"
    wait(5s)
    Redirect(Homepage)
}

これが例外処理の最も安全な方法です。以下のコードは安全ではないので使用しないでください:

if(!$_GET['userID'] === object.ownerID) {
    echo "このデータの閲覧は許可されていません"
    wait(5s)
    Redirect(Homepage)
}
ShowData()

リダイレクトによりデータは表示されませんが、戻るボタンを押すとデータが表示されてしまう可能性があります。

オブジェクトIDに基づく

この脆弱性は、サーバーがオブジェクトに対する利用権限を適切に確認しないままオブジェクトIDが渡される場合にも発生します。例えば、あるリソースだけを守り、他は守らなくても良いと判断した際に、守るべきオブジェクトの防御設定を忘れるケースが考えられます。

攻撃例

どの種類の場合でも、共通する点がいくつか存在します。

これらの問題は、特に2つの状況で発生しやすいですが、もちろん、開発者が認証設定を忘れた場合にはいつでも発生し得ます。ここでは2つの例に焦点を当てます:

• 機能を開発中、長期間経過した後に変更や追加が必要になる場合、十分なドキュメントが存在せず、開発開始時には機能の一部が忘れ去られている可能性があります。その結果、初期の認証要件が抜け落ち、上書きまたは削除される恐れがあります。
  
  

1. 例えば、商品を追加する機能を作成した際、利用者は自身の商品だけを編集できるようにすべきです。商品に対しては以下の3つの呼び出しが考えられます:

• GET product.php?id=12：詳細の取得
• POST product.php?id=12：商品の詳細更新
• DELETE product.php?id=12：商品の削除

2. これらの呼び出しは安全で、利用者は自分自身のオブジェクトに対してのみ実行できます。
3. その後1年経過し、CSVを用いて商品をインポートする機能を追加しようとした場合:

• POST /import.php? で、CSV本文に id, name, price: {1,"test",12} を含める

4. 問題は、開発者がid=1の商品に対する書き込み権限の確認を怠ったため、攻撃者が自分のものでない商品の詳細を上書きできてしまう点にあります。

POST updateProduct.php?productID?id=1
if($_GET['productID'].owner === object.ownerID){
    UpdateData()
} else {
    echo "このデータの閲覧は許可されていません"
    wait(5s)
    Redirect(Homepage)
}

POST /import.php?
StartUpdateData()

この擬似コード例では、説明した脆弱性が実際に動作している様子が確認できます。

• 異なる機能同士が統合される場合、セキュリティ上の配慮が見落とされやすいです。なぜなら、これらの機能は別々に、あるいは別チームで開発されることが多く、注意を欠くと必要なチェックが実装されないままになってしまうからです。
  
  

• 例えば、利用者がサイトを利用している際、サプライヤーの商品情報に基づいて10分ごとに自社商品の価格を更新する機能を作成する場合、バックグラウンドで価格をチェックする呼び出しが行われることがあります。攻撃者はオブジェクトIDを単に置き換えることでこの呼び出しを悪用し、価格情報を取得する可能性がありますが、その呼び出しがバックグラウンドで行われるため気付かれにくいのです。

TimerForProducts(){
    wait(24H)
    UpdatePrices($_GET[UsersProducts[])
}
UpdatePrices(products[]) {
    for each product in products{
        getPrice()
    }
}
GET /updatePrices?UsersProducts=1,2,3,4

攻撃者は、任意のproductIDを渡すことでこのバックグラウンド呼び出しを簡単に悪用できます。

GET /updatePrices?UsersProducts=1,2,3,4,5,6,7,8,9,...

Broken Object Level Authorizationの検出と防止方法

検出

この脆弱性を検出するためには、許可されたすべてのオブジェクトに対して、読み取り、更新、削除の動作をテストする必要があります。検出手法は次の2通りです:

• 対象の各objectIDを、許可されていないIDに置き換え、呼び出しが成功するか確認する。
• 自社の認証トークンを他の利用者のトークンに置き換え、自社オブジェクトを閲覧する。この方法は自動化しやすいという利点があります。objectIDは名称が異なる場合が多いですが、認証ヘッダーは常に同じためです。

どの方法を採用する場合でも、すべてのオブジェクトについて読み取り、更新、削除のチェックを行うことが不可欠です。手動での追加だけでなく、CSVでのインポートなど二次的なルートによる機能も対象に含める必要があります。

防止

Broken Object Level Authorizationの欠陥を防ぐための一般的な対策はこちらにまとめられています。これらの対策により、脆弱性の発生を防ぐか、発生時の影響を低減できます。

• 利用者IDをパラメータとして送信するのではなく、JWTなどの認証トークンを利用し、そこから利用者IDを抽出する。
• IDには常にGUIDを使用する。GUIDは長くランダムな文字列で構成されるため、他の利用者の識別子を推測しにくくなります。
• すべての重要なオブジェクトで共通して使える中央集権的な認証ソリューションを構築する。これにより、各所で異なる認証機構が乱立するのを防げます。
• その認証機構を利用して、非公開すべきオブジェクトの読み取り、削除、更新を検証する。
• 既存の認証機構が意図した通りに動作することをテストで確認する。
• API Security Platformを利用する。

‍

結論

アプリの機能が増え、APIが次々と構築される中で、Broken Object Level Authorizationの欠陥はますます広がっています。この脆弱性は深刻であり、サーバーの設定が不十分な場合、リクエスト内の数字を置き換えるだけで簡単に悪用される可能性があるため、ホワイトハッカーによる検証が重要となります。

オブジェクトを扱い、IDを受け取るすべてのエンドポイントでは、必ずObject Level Authorizationを適用し、対象オブジェクトに対して操作を試みる利用者が正しい権限を持つか確認する必要があります。

適切な認証チェックを実施し、権限のないオブジェクトに対する操作を確実に防ぐことが非常に重要です。

弊社のOWASP Top 10の記事もご参照いただき、現在の脆弱性の状況をご確認ください。