【情報処理安全確保支援士試験 令和6年度 春期 午後 問3 設問3】認可制御の不備
情報処理安全確保支援士試験の解説シリーズ、第3弾へようこそ！前回までのXSS、CSRFに続き、今回はWebアプリケーション脆弱性の代表格であり、OWASP Top 10でも常に上位にランクインする「認可制御の不備」について徹底解説します。
この脆弱性は非常にシンプルですが、それゆえに見落とされがちで、情報漏えいの重大な原因となります。基本をしっかり押さえて、得点源にしていきましょう！
情報処理安全確保支援士試験 令和6年度 春期 午後 問3
【出典：情報処理安全確保支援士試験 令和6年度 春期 午後 問3（一部、加工あり）】
[認可制御の不備について]
Z社が認可制御の不備を検出した経緯は、次のとおりであった。
⑴Z社は、利用者α、利用者βという二つの利用者アカウントを用いて注文履歴を閲覧した際のリクエストを確認した。注文履歴を閲覧した際のリウエストを図5及び図6に示す。
⑵図5のリクエストのパラメータorder-codeの値を図6中の値に改変してリクエストを送った。
⑶利用者αが本来は閲覧できないはずの利用者βの注文履歴を閲覧できるという攻撃が成功することを確認した。
⑷さらに、ある利用者がほかの利用者が注文した際のorder-codeを知らなくても、④ある攻撃手法を用いれば攻撃が成功することを確認した。
Z社は、⑤サイトXのWebアプリに追加すべき処理を説明した。
まずは「認証」と「認可」の違いから
本題に入る前に、よく似ていて混同しがちな2つの言葉「認証」と「認可」の違いを明確にしておきましょう。
- 認証 (Authentication): 「あなたは誰？」を確認するプロセスです。IDとパスワードによるログインなどがこれにあたります。本人であることを確認する「関所」のようなイメージです。
- 認可 (Authorization): 「あなたに何をする権限がある？」を制御するプロセスです。関所を通った後、「あなたは一般エリアには入れますが、関係者以外立入禁止のエリアには入れませんよ」と制御することです。
今回の脆弱性「認可制御の不備」は、この「認可」のチェックが漏れていたために発生しました。
問題の状況：誰の注文履歴でも見放題！？
サイトXで見つかった「認可制御の不備」の状況を整理します。
- 舞台: サイトXの「注文履歴閲覧」機能。
- 脆弱性: 本来、利用者は自分の注文履歴しか見れないはず。 しかし、リクエストのパラメータorder-codeを他人のものに書き換えるだけで、その他人の注文履歴を閲覧できてしまった。
- order-codeの形式: 「注文年月（数字6桁）」と「ランダムな英大文字6桁」をハイフンでつないだもの（例: 202404-AHUJKI）。
ログイン（認証）はしているものの、他人の注文履歴を見る権限がないはずなのに見えてしまう。まさに「認可」の不備ですね。
【設問3 (1)】IDを知らずに情報を盗む「ブルートフォース攻撃」
(1) 本文中の下線④について、どのような攻撃手法を用いれば攻撃が成功するか。30字以内で答えよ。
問題文には、「ほかの利用者が注文した際のorder-codeを知らなくても、ある攻撃手法を用いれば攻撃が成功する」とあります。 他人のIDを知らないのに、どうやって攻撃するのでしょうか？
ここで鍵となるのが、先ほど確認したorder-codeのフォーマットです。
（注文年月6桁）-（ランダムな英大文字6桁）
- 前半の「注文年月」: 例えば「2024年4月」の注文なら「202404」です。これは非常に推測しやすいですね。
- 後半の「ランダムな英大文字6桁」: ここが攻撃のターゲットです。
攻撃者は、このランダムな6文字部分を、考えられる全ての組み合わせで片っ端から試していきます。
202404-AAAAAA 202404-AAAAAB 202404-AAAAAC … 202404-ZZZZZZ
このように、プログラムなどを使って力任せに全てのパターンを試行する攻撃を「ブルートフォース攻撃（総当たり攻撃）」と呼びます。
人間が手で入力するのは無理ですが、ツールを使えば高速にリクエストを自動生成して送信できます。数撃てば当たる戦法で、いずれ誰かの有効なorder-codeに行き着いてしまう可能性があるのです。
したがって、解答は「order-codeの下6桁を総当たりで試行する。」となります。
【設問3 (2)】正しい「持ち物チェック」の実装方法
(2) 本文中の下線⑤について、サイトXのWebアプリに追加すべき処理を、60字以内で具体的に答えよ。
では、この脆弱性を防ぐためには、どのような処理を追加すれば良いのでしょうか。 現在のダメな処理は、「リクエストで送られてきたorder-codeが存在すれば、誰からのリクエストであってもその注文履歴を表示してしまう」という状態です。
これを修正するには、「その注文履歴を見る権限が、リクエストを送ってきた人にあるか？」というチェック、つまり「認可」処理を追加する必要があります。
【あるべき処理の流れ】
- リクエスト主を特定する: まず、リクエストを送ってきたのが誰なのかを特定します。本文より、サイトXではログインセッションをSESSIONIDというCookieで管理しています。 サーバーは、このSESSIONIDを手がかりに「今リクエストを送ってきたのは利用者Aさんだな」と判断します。
- リソースの持ち主を特定する: 次に、リクエストされたorder-codeが、データベース上で誰の注文履歴なのかを確認します。「この注文履歴は利用者Bさんのものだな」と判断します。
- 比較・検証（ここが最重要！）: 手順1で特定した「リクエスト主（利用者Aさん）」と、手順2で特定した「リソースの持ち主（利用者Bさん）」が、同一人物であるかを比較します。
- 判定:
- 一致した場合: 正当なリクエストなので、注文履歴を表示します。
- 一致しない場合: 他人の情報を盗み見ようとしている不正なリクエストなので、エラー画面を表示するなどしてアクセスを拒否します。
この一連のチェックこそが、追加すべき正しい認可処理です。 この流れを簡潔にまとめたものが、解答例の「cookieの値で利用者アカウントを特定し、order-codeの値から特定したものと違っていれば、エラーにする。」です。
まとめ：認可制御の鉄則を忘れずに
今回の設問から、アクセス制御における重要な教訓を学ぶことができました。
- IDは推測困難に: そもそもorder-codeのランダムな部分がもっと長かったり、数字や記号も混ざっていれば、ブルートフォース攻撃の難易度は格段に上がります。IDは推測されにくいものに設計することが重要です。
- ユーザーからの入力を信用しない: ユーザーのブラウザから送られてくるパラメータ（今回のorder-codeなど）は、いくらでも改ざん可能です。それを鵜呑みにせず、必ずサーバーサイドで「その操作を行う権限があるか」を再検証することが、認可制御の絶対的な鉄則です。
この「認可制御の不備」は、非常に基本的でありながら、今なお多くのWebサイトで発見される深刻な脆弱性です。仕組みをしっかり理解し、安全な設計・開発を心がけましょう。
お疲れ様でした！次回はいよいよ最終回。クラウド特有の脆弱性も絡んでくる【設問4】のSSRFについて解説します。最後まで一緒に駆け抜けましょう！
