対象試験と出題頻度
「ログインしたまま別のサイトを開いていたら、いつの間にか身に覚えのない投稿がされていた」。
こんな被害を生むのがクロスサイトリクエストフォージェリです。利用者は何も悪い操作をしていないのに、ログイン状態を勝手に利用されてしまう。SG・FE・APで安定して問われる重要テーマです。
名前がそっくりなXSSと並んで、Webアプリの脆弱性を突くサイバー攻撃として出題されます。両者を取り違えさせる選択肢が定番のひっかけです。
対象試験・頻度の詳細
情報セキュリティマネジメント
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
セキュリティを勉強していると、「CSRFって、結局誰が何をされる攻撃なの？」と整理がつかなくなりますよね。
クロスサイトリクエストフォージェリ（Cross-Site Request Forgery／CSRF）とは、一言で言うと
「ログイン中の利用者になりすまし、本人が意図しない処理を正規サイトに実行させる攻撃」
のことです。
イメージとしては、「他人のハンコを勝手に押した偽の申請書」です。
あなたがハンコ（＝ログイン状態）を机に出しっぱなしにしている隙に、第三者が用意した申請書をあなたの名義で役所に提出してしまう。役所はハンコが本物なので「本人の正式な申請」として受理します。
CSRFも同じで、サーバは正規利用者からの正当なリクエストだと信じて処理を実行してしまうのです。
📊 CSRFの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Cross-Site Request Forgery（略称 CSRF、シーサーフとも） |
| 攻撃の分類 | Webアプリケーションの脆弱性を突く攻撃 |
| 狙われる弱点 | リクエストが「本人の意図によるものか」を確認しない不備 |
| 主な被害 | 勝手な投稿・退会・送金・設定変更などの不正操作 |
解説
セキュリティ攻撃系は、攻撃が成立する「流れ」を追うと理解が深まります。ここでは攻撃のステップ、なぜ成功するのかという原因、そして対策の順に整理します。
攻撃の流れ（4ステップ）
① 前提
被害者が、ある正規サイト（銀行・SNSなど）にログインした状態でいる
② 罠を踏ませる
攻撃者が用意した罠ページ（不正なリクエストを送る仕掛け入り）を被害者に開かせる
③ 勝手に送信
ブラウザがCookie（ログイン情報）を自動付与し、正規サイトへリクエストを送ってしまう
④ 処理が実行される
サーバは本人の操作と信じて、送金・退会・投稿などを実行してしまう
▲ 被害者は罠ページを開いただけ。攻撃者はログイン情報を盗まず「ログイン済みの状態」を利用する
なぜ成功するのか（原因）
原因は、ブラウザが「対象サイトへのリクエストには、保存済みのCookieを自動的に付ける」という仕組みにあります。
サーバ側がCookieだけを根拠に本人確認していると、リクエストがどのページから送られたか（本人の意図か、罠ページからか）を区別できません。
攻撃者はパスワードを盗む必要すらなく、被害者がログイン中であるという状態だけを悪用します。
<!– 攻撃者の罠ページに仕込まれたフォーム（被害者が開くと自動送信） –>
<form action="https://bank.example/transfer" method="POST"> <input type="hidden" name="to" value="attacker"> <input type="hidden" name="amount" value="100000"> </form> <script>document.forms[0].submit();</script>
// 被害者のCookieが自動付与され、本人の送金として処理されてしまう
対策（トークンによる本人意図の確認が本丸）
最も確実な対策は、推測困難な秘密の文字列「トークン（ワンタイムトークン）」をフォームに埋め込み、送られてきたリクエストにそれが含まれているかをサーバで照合する方法です。
罠ページはこのトークンを知り得ないため、不正なリクエストははじかれます。
| 対策 | 内容 |
|---|---|
| トークン照合 | フォームに秘密のトークンを埋め込み、サーバで一致を確認する。最も標準的な根本対策 |
| 重要操作時の再認証 | 送金・退会などの直前にパスワードを再入力させ、本人の意図を確かめる |
| Referer確認 | リクエストの送信元ページが正規のものかをHTTPヘッダで確認する（補助的） |
| SameSite属性 | 他サイトからのリクエストにCookieを付けないようブラウザ側で制限する |
覚えるのはここだけ｜CSRFの要点
・ログイン中の利用者になりすまし、意図しない処理を実行させる攻撃
・攻撃者はパスワードを盗まず「ログイン済みの状態」だけを悪用する
・主な対策はトークン照合。再認証やSameSite属性は補助
この対策の有効・無効の判定は、過去問でそのまま選択肢になります。
試験ではこう出る！
SG・FE・APでの出題は「手口を選ぶ」型と「効果のある／ない対策を選ぶ」型の2系統です。特にXSSとの違いを突く問題が多いのが特徴です。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H26春 午前 問40 |
攻撃と対策の適切な組合せを選ぶ問題。 | ・CSRFとXSSの説明を取り違えさせる選択肢が並ぶ |
| SC H31春 午後Ⅰ 問10 |
CSRFの仕組みを説明する記述を選ぶ問題。 | ・「セッション管理の脆弱性を突く」点が判定の決め手 |
| SC R7秋 午前Ⅱ 問16 |
CSRF対策として効果がないものを選ぶ問題。 | ・トークンや再認証は有効、的外れな対策が不正解として混入 |
📝 ひっかけ選択肢の傾向
傾向1：XSSの説明とすり替える
「悪意あるスクリプトを実行させてCookieを盗む」はXSSの説明であり、CSRFの正解ではありません。名前が似ているため最頻出のひっかけです。CSRFは「スクリプトの実行」ではなく「意図しないリクエストの送信」が核心と覚えてください。
傾向2：効果のない対策を正解に見せる
対策を問う問題では「送信元IPアドレスで制限する」「ウイルス対策ソフトを導入する」などが選択肢に並びますが、これらはCSRFには無力です。正解は「トークンの照合」または「重要操作時のパスワード再認証」になります。
頻出キーワードは「ログイン状態（セッション）」「意図しないリクエスト」「なりすまし」「トークン」。判別に迷ったらXSSとの違いを思い出すのが近道です。
【確認テスト】理解度チェック
Q. クロスサイトリクエストフォージェリ（CSRF）の手口の説明として、最も適切なものはどれでしょうか？
- A. ログイン中の利用者を罠ページへ誘導し、ブラウザに保存されたセッション情報を悪用して、本人が意図しない処理を正規サイトへ実行させる。
- B. 脆弱なWebサイトの入力欄に悪意あるスクリプトを埋め込み、それを閲覧した利用者のブラウザ上で実行させてCookieを盗む。
- C. データベースへの問合せ文を不正に書き換えるSQL文を入力欄に送り込み、許可されていないデータの取得や改ざんを行う。
正解と解説を見る
正解：A
解説：
選択肢Aが、ログイン状態を悪用して本人が意図しない処理を実行させるという、CSRF固有の手口を正確に表しています。「セッション情報の悪用」「意図しない処理の実行」が判定の決め手です。
選択肢BはXSS（クロスサイトスクリプティング）の説明です。スクリプトをブラウザで実行させる攻撃であり、リクエストの送信を悪用するCSRFとは仕組みが異なります。選択肢CはSQLインジェクションの説明です。データベースへの問合せ文を不正操作する攻撃で、利用者のログイン状態を悪用するCSRFとは狙う対象が異なります。
よくある質問（FAQ）
Q. CSRFとXSSの一番の違いは何ですか？
「サーバを信用させる側」が逆だと考えると整理できます。CSRFは、サーバが利用者からのリクエストを信用してしまう弱点を突き、なりすましで処理を実行させます。XSSは、利用者のブラウザがサーバから来た内容を信用してしまう弱点を突き、スクリプトを実行させます。CSRFはスクリプトの実行を必ずしも伴わない点も大きな違いです。
Q. 送信元IPアドレスで制限すればCSRFは防げますか？
防げません。CSRFのリクエストは被害者本人のブラウザから送信されるため、送信元IPは正規利用者のものになり、攻撃者のIPを遮断する発想では止められないからです。試験ではこの「送信元IPで制限」が効果のない対策として選択肢に頻出します。有効なのはリクエストの中身（トークン）で本人の意図を確認する方法です。
Q. SameSite属性とは何ですか？トークンと何が違いますか？
SameSite属性は、Cookieに付与する設定で「他サイトから来たリクエストにはこのCookieを送らない」とブラウザに指示する仕組みです。トークンがアプリ側で照合する能動的な対策なのに対し、SameSiteはブラウザ任せの防御層という違いがあります。近年は両方を併用するのが実務の主流で、SameSite=Lax以上の設定が推奨されます。
Q. ログアウトしていればCSRFの被害は受けませんか？
基本的には受けにくくなります。CSRFはログイン状態（有効なセッション）の存在を前提にするため、こまめにログアウトしておけばリスクは下がります。ただし「ログインしっぱなしを保つ」設定を使っている場合や、複数タブで作業している場合は気づかぬうちにセッションが有効なことがあります。利用者側の自衛だけに頼らず、サーバ側でトークン照合を実装することが本質的な解決策です。
