この記事では，令和６年度 春期 情報処理安全確保支援士試験 午後問題 問３を図解入りで解説します！
各解説につきましては，独自の見解です．正確性を保証するものではありませんので，ご了承ください．
情報処理安全確保支援士試験に向けて勉強されている方の参考になれば幸いです．
本記事における出典：令和６年度 春期 情報処理安全確保支援士試験 午後 問３
IPA（問題冊子・解答例・採点講評）のリンク
本記事内の解答例については，全てIPA公式からの引用になります．
設問１ 〔XSSについて〕
読解力と知識の融合問題です．
（１） 図3中のリクエスト内のスクリプトが出力される機能
図3は，脆弱性診断ツールによる問い合わせ機能のリクエストとレスポンスを示したものです．
リクエストボディのnameパラメータには，“><script>alert(1)</script><”をURLエンコードした値が格納されています．
また，表1 「サイトXの機能一覧（抜粋）」によれば，サイト管理機能（ログイン後）として，問合せ管理機能（項番9）が用意されており，そこでは問合せ機能（項番5）で入力された問合せ情報が閲覧できる仕様になっています．
以上を踏まえた上で，下線①（問題冊子25ページ）の文章を見てみましょう．
（前略） ① 設計書を調査した上で手動による分析を行い，図３中のリクエスト内のスクリプトが別の機能の画面に出力されることを確認した．
解答例
９
解説
表1の項番9に着目してみると，「問合せ機能（項番5）で入力された問合せ情報が閲覧できる．」とあります．
（２） 攻撃者が利用者情報を取得する手順
Z社は，② 攻撃者がこのXSSを悪用してサイトX内の全会員の利用者情報を取得する可能性があると説明した。
解答例
攻撃者がわなリンクを用意し，管理者にそのリンクを踏ませることで管理者権限のcookieを攻撃者のwebサイトに送信させ，その値を読み取って利用することで管理者としてサイトXにアクセスし，利用者情報を取得する。
解説
サイトXの仕様について，問題冊子23ページ上部に「サイトXのログインセッション管理は，cookieパラメータのSESSIONIDで行う」旨の記述があります．従って，ログイン済みユーザのcookieが何らかの方法により窃取されると，当該ユーザになりすまされる可能性があります．
また，Cookieが窃取されたユーザが管理者であった場合，自ずとサイトXの管理者権限を攻撃者に奪取されることになり，会員管理機能を悪用されると，全利用者の情報を不正に取得されてしまう恐れが出てきます．
攻撃全体のイメージとしては，上図のような感じです．サイト管理者が思わずクリックしたくなるようなリンクテキストの裏で，Cookieの値をクエリパラメータ（またはリクエストボディ）に格納し，攻撃者のサイトへGET（またはPOST）アクセスするといった要領です．
これらをまとめると，「攻撃者がわなリンクを用意し，管理者にそのリンクを踏ませることで管理者権限のcookieを攻撃者のwebサイトに送信させ，その値を読み取って利用することで管理者としてサイトXにアクセスし，利用者情報を取得する。」のような解答になります．
設問２ 〔CSRFについて〕
サイトXでは，POSTリクエストボディにCSRFトークンが含まれない場合は，エラー処理がなされていますが，CSRFトークンが含まれてさえいれば（仮に，それが異なる利用者のアカウントで取得したCSRFトークンであったとしても），正常に処理されてしまう脆弱性があるシナリオのようです．
（１） 下線③について，攻撃の手順
「手順３（異なる利用者のアカウントで取得したCSRFトークンをリクエストに含めて送信した場合）の応答が“正常に処理”であることから③利用者に被害を与える可能性があると判断した。」
解答例
攻撃者が自らのアカウントで取得した csrf_token と一緒に利用者情報をサイトXに送るように構成したわなフォームに，詐欺メールなどで利用者を誘導し，利用者情報を変更させる。
解説
何かしらの適当なフォームページを用意しておき，攻撃者が自らのアカウントで取得した csrf_token，利用者情報（例えば，攻撃者のメールアドレス）一式をhiddenパラメータに格納し，サイトXにPOST送信する構成にしておきます．
そして，詐欺（フィッシングメール）等を使って，前述の要領で用意した適用なフォームページにサイトX（ログイン済み）のユーザを誘導し，後はユーザがわなフォームの「送信」ボタンをクリックすれば，利用者情報を不正に（正規利用者のメールアドレスから，攻撃者のメールアドレスに）変更できるという寸法です．
CSRFトークンの実装では当然，本人のアカウントで発行されたCSRFトークンであるか否かを検証する処理も必要です．Webアプリケーションフレームワークの中には，CSRF対策処理一式（トークン発行，紐付け，フォームへの埋め込み，検証処理）を簡単かつ堅牢に実装できるものがありますので，そちらを活用すると良いでしょう．
例えば，Laravelではformタグの中に @csrf と記述するだけで，上記の処理一式を実装してくれます．むしろ，デフォルトでは @csrf を書かずにPOSTした場合，419エラーになってしまいます．かなり堅牢な仕様ですね．
（２） 表３中の a～d に当てはまる記号
CookieのSameSite属性に関する知識問題です．
解答例
a）× b）× c）〇 d）×
解説
典型的な知識問題（記号）ですが，多少はメタ読みが通用する問題でもありました．
Strict，Lax，None はそれぞれ 厳格な，緩い，無し という意味です… と言っても，メタ読みの解説をしたところでどうしようもないので，真面目に解説します．
CookieのSameSite属性による挙動の違いは，mdn web docs のページに記載されていますので，そちらが参考になるかと思います．
Cookieの設定に関する補足は，以下の記事をご覧ください．
設問３ 〔認可制御の不備について〕
論述問題２題の出題でした．論述ではありますが，答えるべき内容としてはいずれの問題も定番パターンであったように思います．
（１） 下線④について，攻撃手法（30字以内）
さらに，ある利用者がほかの利用者が注文した際の order-code を知らなくても，④ ある攻撃手法を用いれば攻撃が成功することを確認した。
解答例
order-codeの下6桁を総当たりで試行する。（26字）
解説
問題冊子23ページの表１「サイトXの機能一覧（抜粋）」の項番3 に「注文履歴は，注文年月である数字6桁とランダムな英大文字6桁の値をハイフンでつないだ注文管理番号で管理される。」とあります．
組み合わせは，$26^6$パターンという膨大な量になりますが，問題文からは，「その中から特定（単一）のコードを突き止めるのではなく，（誰の何の注文でも良いから）他人の注文履歴を閲覧できてしまう」と解釈できます．
従って，下6桁を総当たりで試行するというのも十分に想定される攻撃の手段です．
余談ですが，情報処理安全確保支援士試験では「〇〇を総当たりで（変えながら）試行する」という答えを書かせる問題が頻繁に出題される印象があります．
私は勝手に“総当たり構文”と呼んでいますが，問題文に「〇桁の文字列」とあったら，まずは“総当たり構文”の存在を思い浮かべてみると良いかと思います．
（２） サイトXのWebアプリに追加すべき処理
下線④（前問）の脆弱性を受けて，サイトXのWebアプリに追加すべき処理を60字以内で答える問題です．（出ました！ 定番パターン）
解答例
cookieの値で利用者アカウントを特定し，order-codeの値から特定したものと違っていれば，エラーにする。（58字）
解説
私はこのような問題を “見せてはいけないデータ表示されている系” ⇒ “検証構文” と呼んでいます．
前問の通り，認可不備により見せてはいけないデータ（ここでは，他人の注文履歴）が見れてしまうのが問題です．
“見せてはいけないデータ表示されている系”と言えば，答えはかなりの高確率で“検証構文”．
cookieの値から特定されるアカウント（cookieの窃取等が無い限り，間違いない）とorder-codeの値（改ざん・偽造されている可能性あり）の一致を検証し，不一致であればエラーにする必要があります．
中学校理科のド定番問題「ガスバーナーの火を消す前にガラス管を抜くのはなぜか？」⇒ 「試験管に水が逆流し，試験管が割れるのを防ぐため．」に似たものを感じます．
設問４ 〔SSRFについて〕
（１） 下線⑥について，ログインできない理由（35字以内）
⑥ 図7のリクエストのパラメータの値をWebサーバYのCMS管理ログイン画面のURLに変更することで，その画面にアクセスできるが，ログインはできないことを確認した。
解答例
変更後のURLにPOSTデータは送ることができないから（28字）
解説
図7のリクエストについて，パラメータに指定できるのはURLのみであり，メソッド（GET，POST 等）やリクエストボディは指定できません．
加えて，問題冊子22頁の[CMSについて]にて，「ログインはPOSTメソッドでのみ許可され，GETメソッドでは許可されない」という旨の記述があります．
上記2点を総合的に考えると，「変更後のURLにPOSTデータは送ることができないから」という解答を導くことができます．
（２） 下線⑦について，クレデンシャル情報を取得する方法
⑦ 図7のリクエストのパラメータの値を別のURLに変更するという方法（以下，方法Fという）でSSRFを悪用して，クレデンシャル情報を取得し，
解答例
パラメータpageの値をIMDSのクレデンシャル情報を返すURLに変更する。
解説
問題冊子22頁に「IMDSは，VPCの各サーバから特定のURLにアクセスされると特定の情報を返す．例えば，https://（省略）にGETメソッドでアクセスされると，クラウドW上のサービスのクレデンシャル情報を返す．」という旨の記述があります．
本来は，インターネットから直接できないIPアドレスになっていますが，SSRFにより不正にアクセスされてしまうという算段です．
（３） 下線⑧について，方法Gでクレデンシャル情報を取得する手順
方法Gを用いれば，方式2に変更しても，⑧ クレデンシャル情報を取得し，
解答例
トークンを発行するURLにPUTメソッドえアクセスしてトークンを入手し，そのトークンをリクエストヘッダに含めて，IMDSのクレデンシャル情報を返すURLにアクセスする。
解説
問題冊子22頁に記載されている方式2をほぼそのまま書き抜く問題（サービス問題）でした．
（４） 下線⑨について，Webアプリに追加すべき処理
解答例
パラメータpageの値がサイトP以外のURLならエラーにする。
解説
再び登場！ “見せてはいけないデータ表示されている系（アクセスできてはいけない系）”からの“検証構文”パターンでした．
