Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures
本論文は 107 件の分類されたバグバウンティ報告書の大規模な実証分析を提示し、アクションレベルのオブジェクト BOLA が支配的でありながら過小評価されている脆弱性ファミリーであることを明らかにし、プラットフォームタグへの依存が破損したオブジェクトレベルの認証の発生率を著しく過大評価していることを示す。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
巨大でハイテクなアパートメント複合施設を歩いていると想像してください。あなたは建物に入るためのキーカード（認証）を持っていますが、本当のセキュリティは、あなたが入室を許可されている「特定の部屋」を確認することにあります。
**Broken Object Level Authorization（BOLA：壊れたオブジェクトレベルの認可）**とは、建物の警備員が、あなたが開けようとしている特定の部屋番号とキーカードを照合するのを忘れた場合に起こります。あなたは正当な居住者かもしれませんが、402 号室を開けようとすると、警備員は「402 号室があなたのものかどうか確認もせず」に「はい、どうぞ」と言います。
この論文は、バグバウンティプログラム（ハッカーがこれらの穴を見つけるために報酬を得る仕組み）からの107 件の実際のセキュリティ報告に関する大規模な調査です。研究者たちは、「理論的」なセキュリティアドバイスを超えて、現実世界で実際に何が起きているかを調べようとしていました。
以下に、彼らの発見を簡単な比喩を用いて解説します。
1. 「ラベルノイズ」の問題（誤報）
研究者たちは、HackerOne 上で「IDOR」（この種のバグの一般的な名称）とタグ付けされた 200 件の報告から調査を開始しました。
- 発見: その報告の**42%**だけが実際に本物でした。
- 比喩: 200 回作動する火災警報システムを想像してください。研究者たちは、その 39% の場合、火事ではなく、誰かがトーストを焼いている、シャワーの蒸気、あるいは壊れたセンサーが原因だったことを発見しました。
- 教訓: システムに「IDOR」というタグが付いているからといって、それが特定の危険な「Broken Object」脆弱性を持っているわけではありません。セキュリティチームはタグを過信するため、リスクを過大評価することがよくあります。
2. 二人の主要な悪役（分類）
研究者たちは、実際のバグを 6 つのカテゴリーに分類しました。そのうち 2 つが明確な勝者であり、全事例のほぼ**80%**を占めていました。
悪役 A: 「Direct Object Reference」（電話帳のトリック）
- 概要:
website.com/invoice/101という URL が見えるとします。番号を102に変更すると、突然誰か他の人の請求書が表示されます。 - 比喩: 一列に並んだ郵便受けの前に立っているようなものです。あなたの箱が#101 だと分かっています。#102 を試すと、鍵が壊れているので開けて、隣人の手紙を読んでしまいます。
- 頻度: 事例の**37%**で発生しました。
- 概要:
悪役 B: 「Action-Level Object」（破壊者）
- 概要: これが大きな驚きです。単に誰か他の人のデータを読むだけでなく、それを変更したり削除したりすることです。
- 比喩: 触ってはいけないはずの隣人の郵便受けに近づき、手紙を読むだけでなく、郵便受けを壁から引き裂き、彼らのメールを削除したり、彼らの金を移転したりします。
- 頻度: 事例の**42%**で発生しました。
- 重要性: ほとんどのセキュリティガイドはデータの「読み取り」に焦点を当てています。しかし、この論文は「悪い人たちは、単に盗み見るよりも、データを破壊し変更していることの方が多い」と述べています。
3. その他の狡猾な悪役
残りの 20% のバグはより複雑でした。
- テナント分離: あなたは共有オフィスビルにいます。異なる会社のオフィススイートのドアを開けようとすると、鍵が効きません。
- ワークフロー・コンテキスト: あなたは会社を解雇されましたが、システムはあなたが以前携わっていたプロジェクトの「アーカイブされた」ファイルへのアクセスをまだ許可しています。システムがあなたのステータスの更新を忘れたためです。
- 連鎖的開示: ID を推測することはできませんが、アプリの別の部分（領収書など）で ID のリストを見つけ、そのリストを使って他の人のアカウントに侵入します。
- オブジェクト再バインディング: リクエスト内の隠しフィールドを変更すること（例えば、文書の「所有者」名を変更するなど）で、システムをあなたがそのオブジェクトの所有者だと勘違いさせます。
4. 「垂直」の驚き（エレベーターの乗車）
通常、これらの攻撃は「水平」（ユーザー A がユーザー B から盗む）と考えられています。
- 発見: 12% の場合、通常のユーザーが管理者に属するものにアクセスしたり削除したりすることに成功しました。
- 比喩: アパートメント複合施設の通常の居住者が、ビル管理者の私室に侵入し、マスターキーを削除してしまいます。
- 教訓: 「管理者は安全だ」と仮定しているため、この巨大なリスクはほとんどのセキュリティチェックリストで無視されています。
5. 「魔法」の ID は機能しない
開発者はよく、「単純な 1, 2, 3 ではなく、長いランダムなコード（UUID）やエンコードされた文字列を使えば安全だ」と考えます。
- 発見: 成功した攻撃の**39%**は、これらの「複雑な」ID を使用していました。
- 比喩: 悪い人たちは郵便受けの「秘密のコード」を解読する方法を見つけ、それが単なる隠された番号であることを悟り、次の郵便受けに行くために番号を単にインクリメントしました。
- 教訓: ID を隠しても問題は解決しません。ID がどのように見えるかに関わらず、サーバーはあなたがそのオブジェクトの所有者かどうかを確認する必要があります。
6. 「GraphQL」の抜け穴
この論文は、多くの現代のアプリが「GraphQL」と呼ばれるシステムを使用していることを発見しました。これらのシステムは「グローバル ID」（gid://hackerone/Report/123 のようなもの）を使用します。
- 発見: 攻撃者はこれらの ID をデコードすると、その下の連続番号が露呈し、次の ID を簡単に推測できることに気づきました。
- 教訓: ID が複雑な文字列のように見えるからといって、それがランダムであるわけではありません。
一般の人へのまとめ
この論文が教えてくれることは以下の通りです。
- タグを信頼するな: システムが特定のバグを持っているとフラグ付けされているからといって、実際にその方法で壊れているわけではない。
- 悪い人たちは破壊的だ: 彼らはデータを盗むだけでなく、私たちが思っていたよりも頻繁にデータを削除し変更している。
- 秘密のコードだけでは不十分だ: サーバーがデータの所有者を確認しない限り、複雑な ID を使ってもハッカーは止められない。
- 通常のユーザーは管理者を傷つけうる: 通常のユーザーアカウントが、時として「ボス」のものを侵入して壊すことができる。
この論文は、セキュリティテストの変更が必要だと結論付けています。私たちは、他人のデータを読み取れるかどうかをチェックするだけでなく、削除したり変更したりできるかどうかをチェックし始め、通常のユーザーが（意図的であれ偶発的であれ）管理者のものを侵入できるかどうかをテストする必要があります。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。