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

IDORからBOLA

歴史的にこの種の脆弱性は、安全でない直接オブジェクト参照として広く認知されていた^[1]。IDORは2007年にOWASPによって初めて導入された概念であり、主にアプリケーションがデータベースの内部キーや連続するIDといった直接的なオブジェクト参照をURLやフォームの隠しフィールド、Cookieなどに露出し、それを攻撃者が予測・改ざんできるという攻撃のメカニズムに焦点を当てていた^[4]。共通脆弱性タイプ一覧（CWE）においては、CWE-639（ユーザー制御のキーによる認証回避）やCWE-706（不適切に解決された名前または参照の使用）に関連付けられている^[5]。

しかし、OWASP API Security Projectは2019年にこの名称をBOLAへと意図的に変更した^[1]。この名称変更は、セキュリティの焦点を「露出のメカニズム」から「根本的なロジックの破綻」へとシフトさせる重要なパラダイムシフトであった^[4]。現代のAPI駆動型アーキテクチャにおいては、オブジェクトIDはURLのパラメータとしてだけでなく、HTTPヘッダー、JSONのペイロード内、ネストされたGraphQLのミューテーション、あるいはマイクロサービスの境界を越えた通信など、あらゆる場所に存在する^[6]。BOLAという用語は、参照の形式が直接的であるか予測可能であるかにかかわらず、オブジェクトレベルにおける認可チェックが欠落している状態全体を包括的に表現する概念として機能している^[4]。

リソース、エンドポイント、およびオブジェクトID

最新のアプリケーションは、多数のリソースとサブリソースの集合体として構成されている。例えば、配車サービスのアプリケーションにおけるリソースには、ユーザー、旅行履歴、領収書、メッセージ、車両などが含まれる^[1]。REST APIアーキテクチャにおいては、これらのリソースはJSONオブジェクトとして表現され、クライアントとサーバー間でやり取りされる^[1]。

これらのリソースに対してCRUD操作を実行するため、APIは特定のエンドポイントを公開する。特定の旅行履歴を取得する「GET /api/trips/{trip_id}」などがその典型例である^[1]。一人のユーザーが同一のシステム内に複数のオブジェクトを持つ設計では、クライアントはAPIに対して「どの特定のオブジェクトに対して操作を行いたいか」を明確に指示する必要があり、その手段としてオブジェクトIDがエンドポイントのパスやパラメータに組み込まれる^[1]。このようにオブジェクトをID経由で公開すること自体は、RESTful APIの標準的な設計であるが、ここに強力な認可メカニズムが伴わなければBOLAの侵入口となる^[1]。

コートチェックの罠

OWASP API Security Projectの共同リーダーであるErez YalonとInon Shkedyの調査からは、「コートチェックの罠」というメタファーが提示されている^[1]。

ある人物がクラブを訪れ、コートチェックの受付にジャケットを預け、代わりに「#26」と印字された番号札を受け取る。数時間後、この人物が番号札の「#26」を「#28」に書き換えて受付に提示した際、受付係が「提示された番号札が本当にその人物に最初から割り当てられていたものか（認可）」を一切確認することなく、単にラックから#28のジャケットを探し出して手渡してしまうという状況である^[1]。

このメタファーにおける各要素は、APIの構成要素と以下のように対応している^[1]。

• コートチェックルーム - インターネット上に公開された脆弱なAPIエンドポイント。
• 受付係 - ユーザーの身元（認証）は確認できても、そのユーザーが要求したオブジェクトに対するアクセス権（認可）を検証するロジックが欠如している脆弱なバックエンドコード。
• ジャケット - データベースに格納され、不適切に露出してしまった機密性の高いデータオブジェクト。

検知の難しさ

BOLAは以下の理由で検知が難しい。

• BOLAの悪用には高度なハッキングツールや複雑なエクスプロイトチェーンを必要としない^[4]。Webブラウザの開発者ツールや単純なスクリプト、プロキシツール（Burp Suiteなど）を用いて、URLやペイロードのパラメータを一つ変更してサーバーの応答を確認するだけで容易に悪用できる^[4]。
• トラフィックの形状が完全に正常に見えるという問題がある。SQLインジェクションなどの従来の脆弱性は、リクエスト内に悪意のある特殊文字を含むためシグネチャベースの検出エンジンによって特定可能である^[4]。しかし、BOLAにおいて送信されるリクエストは、構文の観点からは正当なフォーマットを保っている^[4]。
• 構文の正当性ゆえに、WAFやAPIゲートウェイ、レート制限システムなどのセキュリティインフラを完全にバイパスしてしまう^[4]。BOLAのトラフィックは、有効なセッショントークンを持った認証済みユーザーが、単に数字を一つ変えただけの構文的に正しいリクエストを送信しているに過ぎないため、WAFはアラートをトリガーすることなく通過させてしまう^[4]。

ツーアカウントメソッド

同じ権限レベルを持つ2つのアカウント間でリソースが保護されているか（水平認可）を検証する手法^[5]。テスターは「ユーザーX」と「ユーザーY」として同時にログインし、ユーザーXのセッショントークンを保持したまま、リクエスト内のオブジェクトIDをユーザーYのものに差し替えて送信する。サーバーが要求を拒否せずデータを返却・変更した場合、BOLAが成立する。この作業には「Authz」や「AuthMatrix」といったBurp Suiteの拡張機能が頻繁に活用される^[1]。

複雑なフローの中で破綻しているケースの探索

単一の直接的なリクエストでは認可が正しく機能していても、複雑なフローの中で破綻しているケースを探索する。例えば、他人のメッセージを直接閲覧するリクエストはブロックされても、そのメッセージスレッドに新しいユーザーを招待するネストされた機能において認可チェックが漏れており、攻撃者が自分自身を他人のメッセージスレッドに招待することでアクセスを獲得するような手口である^[1]。

リバースエンジニアリング

公式ドキュメントが提供されていない場合、ブラウザに読み込まれるJavaScriptファイルなどを解析し、非公開のAjaxリクエスト構造や隠しパラメータの手がかりを抽出する^[1]。モバイルアプリケーションのテストにおいては、APKやIPAファイルをリバースエンジニアリング（逆コンパイル）し、ハードコードされたAPIキーやエンドポイントの構造を抽出して傍受・解析を行う^[7]。

ブラインドBOLA

リクエストの応答は正常に見えるが、バックエンドで非同期処理が行われてデータが改ざんされる「ブラインドBOLA」の検証や、BOLAを他の脆弱性と組み合わせる手法。非公開ファイルの名前を変更できる程度の低深刻度のBOLAに悪意のあるJavaScriptコードを埋め込み、「BOLA + 蓄積型XSS」という強力な攻撃チェーンに昇華させてアカウントの完全な乗っ取りを引き起こす^[1]。

HTTPパラメータ汚染

単一のリクエスト内に全く同じパラメータを2つ含めることで認可ロジックを混乱させる手法。WAFや認可フィルターが最初のパラメータを検証してアクセスを許可し、バックエンドのアプリケーションが2つ目の改ざんされたパラメータを処理してしまう挙動を悪用する^[1]。

T-Mobile

米国の大手通信キャリアであるT-Mobileは、BOLAによって複数回にわたり深刻な被害を受けている^[4]。2017年、同社のWeb APIインターフェースにおいて、顧客の電話番号をパラメータとして受け取る設計でありながら、リクエスト元のユーザーがその電話番号の所有者であるかを検証する認可メカニズムが欠落している欠陥が発見された^[1]。これにより、任意の電話番号を入力するだけで、顧客のメールアドレス、デバイス識別データ、IMSI番号、アカウント回復用のセキュリティ質問の答えなどの機密情報を無制限に抽出されるリスクが生じた^[1]。サイバー犯罪者はこのデータを元にカスタマーサポートを騙してSIMカードをハイジャックする「SIMスワッピング攻撃」を展開した^[1]。

さらに2023年には、URL内の単一のアカウント識別子を改ざんするだけで他者のデータにアクセスできるという典型的なBOLA脆弱性を突かれ、3,700万人もの顧客データが流出するインシデントが発生した^[4]。この攻撃では、1カ月以上にわたり毎日平均90万2,000人分のデータを抽出し続けていたにもかかわらず、レート制限や時系列の異常検知システムをトリガーしない「Low and slow attack」が成功していた^[8]。同社は最終的に3億5,000万ドルの集団訴訟和解金を支払う事態となった^[4]。

Uber

モバイルアプリとバックエンド間で通信を行う特定のAPIエンドポイントがユーザーIDを受け取る設計となっていたが、認可チェックが完全にバイパスされていたことをセキュリティリサーチャーのAnand Prakashが発見した^[1]。リクエスト送信者が他人のユーザーIDを使用してクエリを送信した場合、APIはエラーを返すことなくそのIDに紐づくプライベートデータをそのまま返却したため、スクリプトを実行すれば全世界の全ユーザーの詳細データベースを丸ごと収穫できる状態にあった^[1]。

Facebook Messenger

2019年、リサーチャーのSarmad Hassan（Juba Baghdad）は、Facebookの統合チャットインフラストラクチャにおいてクリティカルなBOLA（IDOR）脆弱性を発見した^[1]。ビデオ通話デバイスであるFacebook Portalのサポートボットチャット機能において画像をアップロードした際、背後で送信されるHTTP POSTリクエスト内の「image_ids」の値を他者の添付ファイルIDに改ざんして再送信したところ、その他者のプライベートな添付ファイルを開示・ダウンロードすることに成功した^[1]。この脆弱性は共通のバックエンドインフラを共有していたFacebookメインチャット、Messenger、Workplaceチャットなどすべてのコアメッセージングプラットフォームに影響を及ぼすものであったため、同社は迅速にパッチを適用し、15,000ドルのバグ報奨金を支払った^[1]。

その他の事例

• Optus（オーストラリアの通信大手） - 2022年、本来公開されるべきではない未認証のパブリックAPIエンドポイントの露出を侵入口として、1,000万件の顧客記録漏洩インシデントが発生し、1,100万ドルの罰金が科された^[9]。
• Peloton（フィットネスプラットフォーム） - APIリクエスト内のユーザーIDを交換するだけで、任意のユーザーの個人データや詳細なワークアウト統計情報に不正アクセスできるBOLA脆弱性が発覚した^[4]。
• Harbor（オープンソースのコンテナレジストリ） - メンテナンスロールしか持たない権限の低いユーザーが、不正なAPI呼び出しを通じてプロジェクトのメタデータを操作し、企業内のプライベートプロジェクトをパブリック設定に反転させられる状態にあった^[4]。
• Bagisto（eコマースプラットフォーム） - バージョン2.3.10未満において、顧客が過去の注文を再注文する機能にBOLA（IDOR）の脆弱性が存在し、他人の注文データへの干渉が可能であった^[10]。

二段構えの認可アーキテクチャ

APIをBOLAから保護するためには、集中管理されたポリシー決定機能と、分散された実行ポイントを組み合わせた二段構えの認可アーキテクチャ（属性ベースアクセス制御: ABAC、またはロールベースアクセス制御: RBAC）の実装が推奨される^[1]。

• 認可決定エンジンの構築 - 組織のユーザーポリシーと階層構造に基づいてアクセス権を決定する、中央集権的なロジックをカプセル化したコアエンジン。共有リソースの評価や、地域管理者が自身の管轄外のオブジェクトに対する操作を拒否するような「階層とスコープの評価」を厳格に行う必要がある^[1]。JWTに対して適切なAPIスコープを付与し、それを評価することが重要となる^[11]。
• 全エンドポイントでの確実な呼び出し - クライアントからの入力を用いてバックエンドのレコードにアクセスするすべての関数・すべてのコントローラにおいて、データベースアクセス処理の直前に必ず認可決定エンジンを明示的に照会するセキュアなコーディングを実践する^[1]。

識別子の難読化とランダム化

オブジェクトのレコードIDとして、データベースのオートインクリメント機能に依存した順次的な連番を使用することは、攻撃者による列挙攻撃を容易にするため避けるべきであるとされる^[3]。代わりに、ランダムで予測不可能なGUIDやUUIDを使用することが推奨される^[3]。ただし、これはあくまで攻撃者による対象IDの推測を困難にするための防御的深層化の一環であり、根本的な認可制御の代替にはならない。

APIの可視化とインベントリ管理

組織が自社のAPIトラフィックの正常なベースラインを把握し、稼働中のすべてのホストとデプロイされたAPIバージョンに関する正確なインベントリを維持することが重要である^[2]。非推奨となった古いバージョンのAPI（ゾンビAPI）や、開発・デバッグ用途で放置されているシャドーAPIは、BOLA攻撃の標的となりやすい^[6]。APIゲートウェイと統合されたAPIセキュリティデータレイクなどを導入し、リアルタイムで検知・遮断する体制の構築が求められる^[12]。

SDLCへのテスト統合

ソフトウェア開発ライフサイクルの全フェーズにおいて、多層的なテストを組み込む。認可メカニズムのロジックを評価するための厳格な単体テストおよび結合テストを記述し、CI/CDパイプラインにおいてテストが一つでも失敗した場合は本番環境へのデプロイをブロックする仕組みを構築する^[3]。また、自動化ツールによる高速スクリーニングと、専門家による手動ペネトレーションテストを併用する定期的なハイブリッド診断が有効であるとされる^[12]。