【ITニュース解説】Why testing broken access control is still mostly a manual job — and what it takes to automate it

Broken Access Controlというセキュリティの脆弱性は、長年にわたり、ウェブアプリケーションのセキュリティ課題の中でも特に上位に挙げられている。これは、許可されていないユーザーが、本来アクセスすべきではないデータや機能にアクセスできてしまうという問題だ。例えば、あなたがオンラインストアで自分の注文履歴を見ているときに、他の誰かの注文履歴も見てしまえるような状況を想像すると分かりやすいだろう。この種の脆弱性は非常に重要であるにもかかわらず、既存の自動スキャンツールでは見つけにくいという特性がある。その理由は、この脆弱性が単純なエラーとして表面化せず、「見た目上は正しい応答」として現れるためだ。

自動スキャンツールは、ウェブアプリケーションにリクエストを送り、その応答を分析することで脆弱性を見つけようとする。例えば、ウェブサーバーが「200 OK」というステータスコードと共に、JSON形式のデータ（例えば、請求書の詳細）を返した場合、スキャナーはその応答が「成功した」と判断する。しかし、この「成功した」応答が、本当にそのリクエストを送ったユーザーに返されるべきものだったのかどうかは、スキャナーには判断できない。例えば、GET /api/invoices/1234というリクエストに対して、請求書番号1234の詳細が返ってきたとしても、それがリクエストしたユーザーの請求書なのか、あるいは他の誰かの請求書なのかを、スキャナーは区別できないのだ。なぜなら、「あなたはこの情報を見るべきではない」という明確なエラーコードや署名が存在しないからだ。この脆弱性を見つけるには、「誰がリクエストしたのか」「請求書1234は誰が所有しているのか」「アプリケーションのアクセス制御モデルが本来どうあるべきなのか」という、アプリケーションの「意味」に関する深い理解が必要になる。これらの情報は、単にネットワークを流れるデータ（トラフィック）だけからは読み取れないため、自動スキャナーの分析能力を超えてしまう。

この種の脆弱性をテストし、自動化しようとすると、いくつかの具体的な困難に直面する。まず、テストには少なくとも二つの異なる「ユーザーアイデンティティ」が必要になる。具体的には、ユーザーAとしてオブジェクト（例：請求書）を作成し、次にユーザーBとして同じオブジェクトにアクセスしようと試みて、その結果を比較するという手順を踏む。そのため、テスト環境には、それぞれ独自のセッション、データ、および権限を持つ二つの独立したユーザーアカウントが用意されていなければならない。これは単に同じユーザーの複数のトークンを用意するのとは異なり、実際にメールアドレスの認証、招待フロー、組織への所属、役割の割り当てといった、アプリケーション固有の複雑なユーザー管理プロセスを経る必要がある。これらのプロセスは通常、API経由ではなく、ユーザーインターフェース（UI）を介して行われることが多く、自動化が非常に難しい部分である。

次に、テスト対象となるオブジェクトのID（識別子）の取得も大きな課題となる。現代の多テナント型アプリケーションでは、オブジェクトIDが単純な連番で表示されることは少なく、多くの場合、オブジェクト作成時のAPI応答、ネストされたデータ構造内、リダイレクトURL、あるいはWebSocket通信のフレーム内など、アプリケーションの「フローの途中」で動的に生成される。テストツールは、これらの動的に現れるIDを正確に捕捉し、それを別のセッションを持つ別のユーザーのリクエストに引き渡す必要がある。これは、アプリケーション内で複数の状態遷移をまたぐデータフローを追跡するという、高度な処理能力を要求する。

さらに、テスト中の「セッション管理」も複雑な問題だ。テストプロセス中に、セッションの状態は刻々と変化する可能性がある。例えば、CSRFトークンが定期的に更新されたり、ユーザーの役割が変更されると他のセッションが無効化されたり、多要素認証（MFA）が特定のルートへのアクセスを制限したり、短い有効期限のJWT（JSON Web Token）が自動的にリフレッシュされたりする。テストツールがこれらのセッション状態の変化に適切に対応できなければ、セッションが突然失われ、401エラー（未認証）が発生してしまう。この401エラーを、誤って「アクセス制御の問題ではない」と判断してしまえば、真の脆弱性を見逃すことになり、これは最悪の結果をもたらす。

テスト結果の「判断」も、人間の専門知識が求められる部分だ。仮にユーザーBがユーザーAの請求書を読み取れたとして、それが本当に脆弱性なのかどうかは、一概には言えない。もしかしたら、そのデータは意図的に組織内で共有される設計だったのかもしれない。あるいは、テストデータの準備に誤りがあり、AとBが同じ組織に属しているのに、テストでは別々のテナントとして扱ってしまったのかもしれない。このような状況で、応答の内容を詳細に分析し、エラーメッセージを読み解き、空の配列が返ってきたのか（情報漏洩ではない）それとも他人のデータが返ってきたのか（情報漏洩である）を区別するには、アプリケーションのセマンティクス（意味論）に関する高度な判断が必要になる。ここでAIのような技術が役立つ可能性はあるが、AIが自信満々に誤った検出結果を報告するリスクも伴う。そのため、すべての検出結果には、生のリクエストとレスポンスの証拠、そしてその判断に至った明確な根拠が必ず付随していなければならない。誤検知は開発チームの信頼を損ない、真の脆弱性の見逃しは顧客のセキュリティ侵害につながるため、どちらも避けるべきだ。

また、アクセス制御のテストは「読み取り」だけでなく、アプリケーションの状態を変更する操作（書き込み）を伴う場合があることも考慮しなければならない。例えば、アクセス制御の脆弱性を確認するために、二重の承認や二重の払い戻しといった操作を試みれば、実際にアプリケーションに損害を与えてしまう可能性がある。テスト自動化は、「この操作が可能かどうかを検証したい」という意図と「実際にこの操作を実行する」という結果を明確に区別し、アプリケーションに実害を与えることなく結果を検証する戦略を取る必要がある。例えば、二回目のリクエストが拒否されることを確認したり、操作の前後で状態を読み取って変化がないことを確認したり、テスト専用のダミーオブジェクトを作成して検証するといった方法が考えられる。

これらの困難を乗り越え、実際に効果的だったアプローチの一つは、単にリクエストを再生するのではなく、「実際のウェブブラウザ」を操作することである。ブラウザを操作することで、人間がアプリケーションを使うのと同じようにセッション状態を確立し、トークンやリダイレクトといった、手作業でリクエストを構築する際には推測に頼らざるを得ない要素も正確に扱えるようになる。そして、テストツールが二つの異なるブラウザセッションを保持し、それぞれ別々のユーザーとしてログインし、オブジェクトへのアクセスを試みることで、一方のユーザーが他方のユーザーのデータを見るべきではない、という「意味」に基づいた比較判断が可能になる。このアプローチこそが、既存のスキャナーが苦手とし、真の価値を生み出す部分であると言える。つまり、単に「リクエストを送信して応答をパターンマッチングする」という思考から、「二つのアイデンティティを保持し、それぞれが見るべきものについて推論する」という根本的なシフトが、Broken Access Controlのテスト自動化において非常に重要なのだ。