クロスサイトリクエストフォージェリ（CSRF）は、ログイン中のユーザーになりすまして、送金・購入・設定変更などの操作を勝手に実行させる攻撃です。

Cookieでログイン状態が維持されていると、罠サイトを閲覧しただけでリクエストが送られ、サーバが正規操作と誤認して処理が完了することがあります。

本記事では、CSRFの読み方や用語の意味から、攻撃の流れと成立条件、起こり得る被害例を整理し、図も交えて分かりやすく解説します。

目次

• CSRF（クロスサイトリクエストフォージェリ）とは
• 【図解】CSRF攻撃の流れ（成立までのステップ）
  • ステップ1：ユーザーが標的サイトにログイン
  • ステップ2：罠リンク送信
  • ステップ3：罠リンクを踏む
  • ステップ4：攻撃レスポンス（罠ページが返る）
  • ステップ5：Cookieが自動付与されたリクエストが送られる
• 被害例（何が起きる？どこが危ない？）
  • 不正送金・不正購入（ネットバンキング／EC）
  • 登録情報の改ざん（メール変更・住所変更・退会）
  • 管理画面の設定変更（権限のあるユーザーほど危険）
  • SNS・掲示板への勝手な投稿（炎上・信用失墜につながる）
• CSRFの対策
  • 対策1：CSRFトークンを正しく実装
  • 対策2：SameSite属性を適切に設定（Cookie送信を抑える）
  • 対策3：Origin/Refererヘッダをチェック（送信元の検証）
  • 対策4：重要操作は再認証・確認ステップ（パスワード再入力等）
• まとめ

CSRF（クロスサイトリクエストフォージェリ）とは

CSRF（クロスサイトリクエストフォージェリ）とは、ログイン中のブラウザに残るCookieを悪用し、本人の意思に反して送金や設定変更などのリクエストを実行させる攻撃です。

読み方は「シーサーフ」で、わかりやすく言うと「ログイン中のあなたの操作を勝手にやらせる」仕組みです。

【図解】CSRF攻撃の流れ（成立までのステップ）

CSRF攻撃の流れは上の画像の５ステップです。

ここでは、それぞれのステップについて説明していきます。

ステップ1：ユーザーが標的サイトにログイン

被害者が標的サイトにログインすると、ログイン状態を保つための情報（セッションIDなど）がCookieとしてブラウザに保存されます。

以後、同じブラウザで標的サイトにアクセスすると、ブラウザはこのCookieを自動的に付けて送るため、サーバは「ログイン済みの本人からのアクセスだ」と判断できます。

ステップ2：罠リンク送信

攻撃者は、被害者を罠サイト（または罠ページ）に誘導するために、メール・SNS・掲示板などでリンクを送ります。ここで重要なのは、攻撃者が被害者のID/パスワードを盗む必要はなく、ログイン中のブラウザを動かすことが目的だという点です。

ステップ3：罠リンクを踏む

被害者がリンクをクリックすると、ブラウザで罠サイトが開きます。

被害者は「ただページを開いただけ」のつもりでも、ページの中に仕込まれた仕掛け（例：自動送信フォームや画像読み込みなど）によって、次のステップが実行されます。

ステップ4：攻撃レスポンス（罠ページが返る）

罠サイトから被害者のブラウザへ、攻撃用のページが返されます。ここには、標的サイトへリクエストを送らせるためのHTMLや仕掛けが含まれます。

例えば、フォームを自動送信したり、特定URLを読み込ませたりして、標的サイト宛てのリクエストをブラウザに発生させる役割を持ちます。

ステップ5：Cookieが自動付与されたリクエストが送られる

罠ページの仕掛けにより、被害者のブラウザが標的サイトへリクエストを送ります。このとき、ブラウザは標的サイト宛て通信に対してCookieを自動で添付します。

標的サイト側にCSRFトークンやOrigin/Refererチェックなどの対策がないと、サーバは「ログイン済みユーザー本人の操作だ」と誤認し、送金・設定変更・退会などの処理を実行してしまいます。

被害例（何が起きる？どこが危ない？）

CSRF攻撃には以下の様に多種多様な被害例があります。

不正送金・不正購入（ネットバンキング／EC）

ネットバンキングやECで、ログイン中のブラウザに残るCookieを利用し、本人の意思に反して送金や商品購入のリクエストを実行させるCSRF攻撃があります。

例えば罠ページを開いた瞬間に「振込先＝攻撃者」「購入＝高額商品」といった処理が送られ、サイト側が正規操作と誤認すると被害が確定します。

登録情報の改ざん（メール変更・住所変更・退会）

登録情報の改ざんのCSRF攻撃として、本人の意思に反してメールアドレス変更や住所変更、退会処理などを実行させられる攻撃があります。

例えば罠リンクを踏むだけで「連絡先を攻撃者のメールに変更」されると、パスワード再設定メールが乗っ取られ、アカウントを奪われる危険があります。

管理画面の設定変更（権限のあるユーザーほど危険）

管理画面の設定変更のCSRF攻撃として、管理者など権限のあるユーザーがログイン中の状態で罠ページを開くと、ブラウザがCookie付きで管理操作のリクエストを送ってしまい、サイト側が正規操作と誤認して設定が変更される攻撃があります。

例えば「権限付与」「公開設定の変更」「支払い先口座の変更」などが実行されると被害が大きくなります。

SNS・掲示板への勝手な投稿（炎上・信用失墜につながる）

SNSや掲示板への勝手な投稿におけるCSRF攻撃として、ログイン中のユーザーが罠ページを開いた際、ブラウザがCookie付きで投稿リクエストを送ってしまい、本人が入力していない内容が「自分のアカウント」から投稿される攻撃です。

悪質な文言やURLが拡散されると炎上や信用失墜につながり、削除対応も追いつかないことがあります。

CSRFの対策

CSRFの対策の基本は多層防御です。

１つの対策だけではなく、複数の対策を施すことでより強固な防御をできるように意識しましょう。

対策1：CSRFトークンを正しく実装

CSRFトークンとは、正規の画面で発行した推測困難な値を送信時に一緒に渡し、サーバ側で一致をチェックして「本人の操作か」を確認する対策です。
トークンがないリクエストは拒否できるため、罠ページからの送信を防ぎやすくなります。

参考記事：トークン方式のCSRF対策を図解：フォーム送信の安全化手順

対策2：SameSite属性を適切に設定（Cookie送信を抑える）

SameSite属性とは、別サイトからのアクセス時にCookieを送るかどうかを制御し、CSRF対策として「勝手にCookie付きリクエストが飛ぶ」状況を減らします。

参考記事：SameSite属性とは？Cookie送信制御でCSRFを防ぐ仕組み

対策3：Origin/Refererヘッダをチェック（送信元の検証）

Origin/Refererチェックとは、リクエストの送信元が自サイトかをヘッダで検証し、別サイトからのCSRFを弾く対策です。

参考記事：同一オリジンポリシー（Same Origin Policy）とは？仕組みと制限範囲を図解

対策4：重要操作は再認証・確認ステップ（パスワード再入力等）

重要操作の再認証とは、退会・メール変更・送金などの実行前にパスワード再入力やワンタイムコードで「本当に本人が今操作しているか」を確認する対策です。

CSRFトークンやOriginチェックをすり抜けても、最終段で止められるのが利点です。

まとめ

CSRF（クロスサイトリクエストフォージェリ）の本記事の内容をまとめると下の通りです。

多層防御を意識して、適切な対策を行いましょう。