FE SUBJECT B
基本情報技術者 科目Bの問題解説：A社の経費精算システムでは、ログイン済み利用者が承認ボタンを…
問題
A社の経費精算システムでは、ログイン済み利用者が承認ボタンを押すと承認IDを含むリクエストが送信される。CookieにはSameSite属性を設定しているが、古いブラウザや連携画面もあり、外部サイトから意図しない承認リクエストを送られるリスクが残っている。
最も適切な対策はどれか。
- ア 承認ボタンの色を目立つ色に変える。
- イ 承認リクエストに、利用者セッションにひも付いた推測困難なCSRFトークンを含め、サーバ側で検証する。（正解）
- ウ 承認IDをランダム文字列に変更するだけにする。
- エ Cookieの有効期限を短くし、トークン検証は行わない。
- オ 承認完了後にメール通知するだけにする。
正解と解説
正解：承認リクエストに、利用者セッションにひも付いた推測困難なCSRFトークンを含め、サーバ側で検証する。
CSRFでは正規Cookie付きのリクエストが利用者の意図と無関係に送られます。重要な状態変更操作では、セッションにひも付いたトークンをサーバ側で検証する必要があります。
IDのランダム化や通知は補助策であり、リクエストが利用者の画面から発行されたかを確認できません。
Hardでの見抜き方：SameSiteなどブラウザ側の仕組みがあっても、重要な状態変更操作ではサーバ側でトークンを検証するのが安全です。通知やIDランダム化は、利用者が意図した操作かどうかを保証しません。
なぜトークンが効くのか：CSRFトークンは、利用者ごとに発行した推測困難な値を画面の隠しフィールド等に埋め込み、送信時にサーバ側の保持値と照合します。外部サイトはCookieは自動送信させられてもこの値を読み取れないため、攻撃者は正しいトークンを付けられず弾かれます。本問のSameSite未対応の古い環境でも、この「読めない値の照合」が独立した防御層として残る点が要点です。
他の選択肢はなぜ違う？
- アボタンの色は攻撃と無関係。
- ウ承認IDのランダム化だけでは、正規Cookie付きの偽リクエストを止められない。
- エCookie有効期限の短縮では、有効な間に送られる偽リクエストを防げない。
- オ完了後の通知は事後で、リクエストが利用者の意図かを検証できない。
この問題について
公開問題・サンプル問題のセキュリティ事例形式（A社シナリオ＋もっともらしい誤答）を参考にした独自問題です。本文・選択肢・解説は新規作成しています。
公式試験問題、公開問題、市販教材、外部問題サイトの問題文を転載・改題したものではありません。