情報処理安全確保支援士 2025年 秋期 午前2 問16

要点まとめ

• 結論：Webサーバでリクエスト中の“<”、“>”などを“<”、“>”に置換する対策はXSS対策であり、CSRF防御には効果がない。
• 根拠：CSRFは利用者の認証済みブラウザを利用して正規のリクエストを偽造する攻撃で、出力エスケープではリクエスト生成自体を止められない。
• 差がつくポイント：CSRF対策は「一意で予測不可なトークン照合」「Referer/Origin確認」「再認証」「SameSite属性」などを組合せることが重要。

正解の理由

よくある誤解（2〜3 行）

解法ステップ

1. 問題の問いを確認：「CSRF対策として効果がないもの」を選ぶ。
2. 各選択肢が何を防ぐ技術かを整理する（再認証／トークン／Referer／出力エスケープ）。
3. CSRFの本質（認証済みブラウザからの正規リクエストの偽装）と照らし合わせる。
4. 出力エスケープはリクエストの生成を阻止しないため、これが「効果がない」選択肢と判断する。

選択肢別の誤答解説

• ア: Webサイトで重要操作の都度パスワード入力を要求する。
  • 有効性：高い。攻撃者は利用者のパスワードを知らないためCSRFを成立させにくい。UX負荷は高いが堅牢。
• イ: ログイン後にレスポンスボディに含めた秘密値とブラウザ送付値をサーバで照合する（CSRFトークン）。
  • 有効性：標準的で有効。トークンはセッション関連付けや予測不可能性が重要。トークンはHiddenフォームやヘッダで送る。
• ウ: リクエスト中のRefererでリンク元を確認する。
  • 有効性：ある程度有効。Originヘッダの方が信頼性高い場合があるが、Refererが消えるケース（プロキシ・プライバシー）に注意。
• エ: リクエスト受信時に“<”、“>”などを“<”、“>”に置換する。
  • なぜ誤りか：これは出力時のエスケープであり、受信した正規のPOST/GETを攻撃と区別して拒否する手段ではない。CSRFの根本対策にならない。

補足コラム（関連知識など）

• SameSite 属性：Set-Cookie に SameSite=Lax/Strict を付与するとクロスサイト送信時のクッキー送信を制限でき、CSRF軽減に非常に有効です。
• Origin ヘッダ：POSTなどで送られる場合、Refererより改変されにくく検証に使える。SPAではトークンと組み合わせることが多いです。
• 実装例（Flask 風にトークン照合の概念）：

# トークン生成（ログイン時）
session['csrf_token'] = secrets.token_urlsafe(32)
# フォームに埋め込む
# フォーム送信時の照合
if request.form.get('csrf_token') != session.get('csrf_token'):
    abort(403)

• フレームワーク: Django, Rails, Spring などはCSRF保護機能を標準で提供しているため、適切に有効化すること。

FAQ