貴社の運営するWebサイトやアプリで、利用者が知らないうちにパスワードを変更されたり、商品を購入されたりしていたらどうでしょうか。
その原因は、「CSRF（クロスサイトリクエストフォージェリ）」と呼ばれる脆弱性かもしれません。
この攻撃は、利用者自身が操作しているように見せかけて、実際には攻撃者の意図した命令を実行させるという巧妙な手法です。
本記事では、「CSRFとは何か？」の基本から、攻撃例、XSSとの違い、防止策までわかりやすく解説します。
CSRFとは？
CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ）とは、ユーザーが意図しない操作を、認証済みのWebサイトに対して実行させる攻撃手法です。この攻撃は、ユーザーがログインしている状態を悪用し、攻撃者がユーザーになりすましてWebサービスに不正なリクエストを送信します。
その操作はユーザー自身の権限で行われるため、システム側では不正と判断されにくいという厄介な特徴があります。
CSRFが発生するリスクが高まる条件
CSRFは、単なる情報提供型のWebサイト（例：企業の会社概要ページ）では発生しません。ログインや購入・登録などの操作を伴うWebサービス全般において発生する攻撃です（※Webアプリを含む）。
CSRFが発生する典型的な条件として、一般的に次の3点が挙げられます。
1. ユーザーが対象のWebサイトにログインしている
（例：ショッピングサイトやSNSにログインしたままの状態）
2. ログイン状態を維持する認証情報（セッションIDなど）がCookieに保存されている
（多くのWebサイトは、Cookieを用いてユーザーの認証状態を管理しています）
3. 攻撃者が、同じ操作を簡単に再現できる
（例：送金先や金額などのパラメータが、URLやフォームにそのまま含まれていて、トークン認証や追加確認がないなど、リクエストの内容が予測・模倣しやすい構造になっている場合）
このような条件が揃うと、たとえば「パスワード変更」「商品購入」「送金」「投稿の改ざん」など、ユーザーの意思とは異なる操作が実行されるリスクが高まります。
CSRFは、ユーザーとWebサービスとの間にある信頼関係を悪用する攻撃であり、その性質上、被害に気づきにくく、気づいたときには取り返しがつかない状況になっていることもあります。
CSRF攻撃の被害例
CSRF攻撃は、ユーザーが自覚しないまま、本人の権限で重大な操作を実行させられるという特徴があります。その被害は個人だけでなく、サービス提供者や企業活動全体にも大きな影響を及ぼす可能性があります。
ここでは、CSRF攻撃によって起こりうる被害を3つの視点から紹介します。
利用者が知らずに被るリスク
CSRF攻撃では、利用者が自分の意思とは無関係に「誰かの意図した操作」を実行させられてしまいます。本人は操作したつもりがないのに、すでに完了している――という状況が典型的な被害です。
代表的な例
- 勝手にSNSへ投稿され、フォロワーを巻き込んでしまう
- ショッピングサイトで意図しない商品を購入される
- パスワードやメールアドレスを第三者に変更される
- オンラインバンキングから知らない相手に送金される
Webサービス側に発生する被害
CSRF攻撃の被害は、サービスを利用しているユーザーだけでなく、そのサービス自体にも重大な影響を及ぼします。代表的なリスク
- スパム投稿や不正アクセスによるブランドイメージの悪化
- 顧客情報の改ざん・消失による業務トラブル
- 脆弱性を放置していたことによる法的責任・行政指導
- 謝罪・調査・補償といった対応に伴うコストの増加
実際に発生したCSRF攻撃の事例
以下は、過去に報告されたCSRF攻撃の実例です。実際の被害がどのような形で表れるのかを知ることで、対策の重要性がより明確になります。
- EC構築システムの脆弱性を突いたカード情報漏えい
2019年、EC構築システムA社に存在していたCSRF脆弱性により、決済画面が改ざんされ、クレジットカード情報が外部に送信される被害が多数発生しました。
参照：IPA「A社システム脆弱性に関する注意喚起」 - CSRFによる高額送金被害の発生
オンラインバンキングにおいて、CSRFを用いた自動送金スクリプトが組み込まれ、利用者の意図しない送金が発生。
被害者がページを開いただけで送金処理が完了していたと報じられています。
参照：Yahoo!ニュース「送金詐欺に使われた手口とその影響」 - SNSでのスパム拡散（通称：はまちちゃん事件）
掲示板に設置された悪意あるリンクを踏んだユーザーが、意図せずSNSでスパム投稿を行う事件が発生しました。
これは掲示板のフォーム設計にCSRF対策がなされていなかったことが原因とされます。
参照：ITmedia「“はまちちゃん騒動”に見る掲示板の脆弱性」
なお、これらの攻撃に遭った場合の被害額については、下記記事をお読みください。
▼サイバー攻撃の企業への被害額は？億単位もありえる被害額｜2024年最新版を公開
CSRFの具体的な攻撃方法
CSRF攻撃は、ユーザーが気づかないうちに「自分の名で操作されてしまう」ことが最大のリスクです。ここでは、CSRFがどのように仕掛けられ、どんな流れで攻撃が実行されるのかを図を交えて説明していきます。
CSRF攻撃の流れ（全体像）
CSRF攻撃は、ユーザーが攻撃者の用意した罠ページを開くことで、本人の意思に反して操作が実行される仕組みです。下図のように、ユーザーが「正規のサイトにログイン済み」であることを悪用し、攻撃者がそのセッションを使って勝手にリクエストを送信します。
図：ユーザーがログイン中のセッションを悪用して、攻撃者が不正操作を実行する一連の流れ
この図では、次のような流れで攻撃が成立しています。
- 1. ユーザーAが、正規のWebアプリケーションにログイン。
- 2. ログイン状態のまま、攻撃者が仕込んだ「罠ページ」を開いてしまう。
- 3. 罠ページに仕込まれたスクリプトが、勝手にパスワード変更などのリクエストを送信。
- 4. 正規サイトは、セッション情報をもとにリクエストを正当と判断し、操作が実行されてしまう。
典型的なCSRF攻撃のステップ
以下は、ECサイトやバンキングサイトなどにログイン中のユーザーが、知らない間に操作を実行させられる一連の流れです。- ① 自分がWebサービスにログイン
例えば、ネットバンキングやショッピングサイトなど、認証が必要なサービスにログインした状態のままブラウザを閉じたり、別タブで他のサイトを見たりします。 - ② 攻撃者が罠ページを用意
攻撃者は、Webページや広告、SNS投稿などに、対象サービスへの「不正な操作」を仕込んだHTMLやJavaScriptを埋め込みます。 - ③ 自分が罠ページを開いてしまう
メールのリンク、SNSのDM、怪しい広告などをうっかり開いてしまうと、そのページが裏で勝手にリクエストを送信します。 - ④ 自分のログインセッションが使われて不正操作が実行
Webサービス側は「正しいユーザーからの操作」と誤認し、パスワード変更・送金・投稿などが実行されてしまいます。
要点まとめ
- ログインしたまま放置しているセッションが狙われる
- ユーザーはクリックしただけ、操作していないのに処理が実行される
- 攻撃者の目的は、ユーザーの認証済みセッションを遠隔操作する
GETメソッドを悪用したケース
Webサイトでは、URLに情報を含めてサーバーに送信する方法として「GETメソッド」という仕組みが使われています。たとえば、検索ページや商品一覧ページで「?keyword=」のようなURLを見たことがある方も多いと思います。
このように、GETメソッドは「送信する内容がURLに含まれる」のが特徴です。
この性質を悪用したCSRF攻撃では、攻撃者がパラメータ付きのURLを用意し、それをユーザーに読み込ませることで不正な操作を行わせます。
たとえば、次のようなURLがあったとします：
`https://example.com/withdraw?account=12345&amount=10000`
攻撃者はこのURLを、小さな画像タグ（imgタグ）に埋め込んでWebページ上に配置することで、ユーザーがページを開いた瞬間にこのリクエストが自動的に送信されてしまいます。
結果として、ユーザーが何も操作していないにもかかわらず、本人の口座から勝手に出金されてしまうような被害が発生する可能性があります。
GETメソッドを利用したCSRF攻撃では、以下のような手法がよく使われます。
• 非表示の画像（imgタグ）を使って自動送信させる
• iframeで攻撃用ページを埋め込む
• JavaScriptで自動リダイレクトさせる
• ソーシャルエンジニアリングでリンクを踏ませる
POSTメソッドを悪用したケース
Webサイトの「お問い合わせフォーム」や「会員登録フォーム」で入力内容を送信するとき、ブラウザはHTTPの「POSTメソッド」を使ってデータをサーバーへ送ります。 これは、ユーザーが入力した内容をURLではなく裏側（リクエストの本文）でサーバーに送る方法で、多くのWebサービスで採用されています。一見すると、POSTメソッドは「見えない場所で送られている」ため安全そうにも思えますが、CSRFの対策がなされていないと、攻撃者に悪用されるリスクがあります。
たとえば、攻撃者が自分のWebサイトに以下のようなコードを埋め込んだ場合を考えてみましょう。
以下は、攻撃者が悪用するHTMLコードの例です。表示されているコードは実行されませんのでご安心ください。
<form action="https://example.com/post-message" method="POST"> <input type="hidden" name="message" value="スパム投稿です！"> </form> <script> document.forms[0].submit(); </script>このコードは、ページには表示されませんが、ページを読み込んだ瞬間に自動で実行されます。
ログイン中のユーザーがこのページを開いてしまうと、本人の意思とは関係なく、指定された内容がSNSなどに投稿されてしまうのです。
POSTリクエストを利用したCSRF攻撃でよく使われる手法には、次のようなものがあります。
- フォームを自動で送信する仕組み
- iframeとJavaScriptを組み合わせた埋め込み
- AJAX（非同期通信）を使ったリクエスト
- FlashやJava Appletなどのプラグイン（現在は減少傾向）
ユーザーは、ユーザーは一切の操作をしていないにもかかわらず、あたかも自分で手続きを行ったかのように処理が完了してしまいます。
その被害はユーザー個人にとどまらず、Webサービスの運営者にとっても大きなリスクとなるため、十分な対策が求められます。
【誤解に注意】CSRFとフィッシングの違いを整理しよう
CSRFとフィッシング攻撃は、どちらも「ユーザーにリンクを踏ませる」という点で似ていますが、目的や仕組みは異なります。- フィッシング：
ユーザーに「偽のログイン画面などに自分で情報を入力させる」ことで、IDやパスワードを盗む攻撃です。 - CSRF：
ログイン中のユーザーに「何も気づかせずに操作をさせる」ことで、ユーザー本人の権限で不正処理を実行させる攻撃です。
フィッシングにつきましては、下記の記事をお読みください。
▼横行するフィッシング詐欺。なりすまし偽サイトを防ぐ企業の対策方法とは？
CSRFとXSSの違いと関係性
CSRFとXSS（Cross-Site Scripting）は、どちらもよく知られたWebアプリケーションの脆弱性ですが、その攻撃手法や目的には大きな違いがあります。両者を正しく理解することで、より効果的なセキュリティ対策を講じることができます。
XSSは、ユーザーのブラウザ上でスクリプトを実行させることで、情報を盗んだり、不正操作を行わせたりする攻撃です。
一方、CSRFは、ユーザーになりすまして認証済みのサイトに不正な操作をさせる攻撃です。
以下の比較表を見ることで、CSRFとXSSの違いがより明確になります。
| 比較項目 | CSRF | XSS |
|---|---|---|
| 攻撃の目的 | ユーザーの権限を借りた操作の実行 | ユーザーのブラウザでのスクリプト実行 |
| 攻撃の対象 | 認証済みユーザーのセッション | ユーザーのブラウザ環境 |
| 主な被害 | 意図しない操作の実行 | Cookie盗難、フィッシング、マルウェア感染など |
たとえば、XSS脆弱性を使ってCSRF対策用のトークンを盗み出し、その情報を使ってより巧妙なCSRF攻撃を実行する――といった複合的な攻撃も現実に存在します。
XSSが「ユーザーのブラウザ」を直接攻撃するのに対し、CSRFは「Webアプリケーションとユーザーの信頼関係」を悪用するという違いがあります。
このように攻撃の性質が異なるため、それぞれに対して異なるアプローチの対策が必要です。
IPA（独立行政法人 情報処理推進機構）の『安全なウェブサイトの作り方』でも、XSSとCSRFの両方に対する包括的な対策の重要性が強調されています。
参照：IPA「安全なウェブサイトの作り方」
クロスサイトスクリプティング（XSS）についての詳細は、こちらの記事で解説しています。
▼クロスサイトスクリプティング（XSS）とは？仕組み・被害事例・対策を図解で解説
CSRF攻撃を受けやすいサイトの特徴とは？
すべてのWebサイトがCSRF攻撃のリスクを持っていますが、特にセキュリティ設計や実装に一定の傾向があるサイトは、より高いリスクにさらされがちです。このような特徴を把握しておくことで、優先的に対策すべきポイントが明確になります。
設計・実装に起因するリスク要因
CSRF攻撃は、Webアプリケーションの設計や実装の仕方によってリスクが大きく左右されます。ここでは、CSRF脆弱性が発生しやすい代表的な要因を紹介します。
- Cookie認証に依存したセッション管理
・Cookie内のセッションIDのみで認証状態を維持している
・二次認証や追加の確認プロセスがない - リクエスト検証の不備
・フォーム送信時のトークン検証が実装されていない
・HTTPリクエストのRefererヘッダーチェックがない - 重要な操作の設計上の問題
・パスワード変更、メールアドレス変更などの操作に再認証がない
・GETメソッドで状態変更操作を実装している - セキュリティヘッダーの未設定
・SameSite Cookie属性が設定されていない、または不適切
・CSP（Content Security Policy）が未設定または不十分
リスクの高いWebサイトのタイプ
以下のようなサービスは、CSRF攻撃の影響が特に大きくなる傾向があります。ネットバンキング・決済サイト： 金銭的被害の可能性が高い
管理機能を持つWebサービス： 権限の高い操作が可能
ソーシャルメディアプラットフォーム： 個人情報やプライバシーが関連
Eコマースサイト： 商品購入、住所変更などの操作
企業の内部システム： 重要データへのアクセス権限がある
さらに注意が必要な実装例
以下のような実装は、CSRF脆弱性の原因となることが多いため、注意が必要です。
- 自動ログイン機能がある
（ログイン状態を長く維持するため、悪用されやすくなります） - 長期間ログイン状態が続く設定になっている
（一度ログインすると何日も再認証されず、CSRFの標的になりやすい） - 複数のサブドメインで同じCookieを使っている
（別のドメイン経由でも認証情報が使えるため、攻撃の足がかりになります） - APIへのアクセスにCSRF対策がされていない
（アプリ内部や外部システムからのアクセス口に対策がなく、攻撃を受けやすくなります） - 古いブラウザへの対応のため、セキュリティ設定を緩めている
（SameSite属性やセキュリティヘッダーなどが正しく機能せず、脆弱になります）
そのため、設計段階から適切なセキュリティ対策を講じ、脆弱性を未然に防ぐことが不可欠です。
CSRF攻撃を防ぐには？
CSRF攻撃は、ユーザーに気づかれないまま重大な操作を実行させるという性質上、発見が遅れやすく、被害も大きくなりがちです。だからこそ、事前に対策を講じることが何より重要です。
この章では、CSRF対策として実践すべき主な手法と、それぞれの目的や効果について解説します。
CSRFトークン（ワンタイムトークン）の導入
最も一般的で効果的なCSRF対策が、トークンを使ったリクエスト検証です。フォームや重要な操作に対して、サーバー側で生成したランダムなトークンを発行し、それをリクエストに含めて送信させます。
リクエスト受信時にそのトークンの正当性を検証することで、第三者による不正な操作をブロックできます。
CSRFトークン（ワンタイムトークン）の導入ポイント
・トークンはセッション単位、またはリクエストごとに発行する
・サーバー側で検証し、不一致時は拒否する
・AjaxやSPAでも同様にトークン送信を徹底する
フォームにCSRFトークンを埋め込む例（HTML）
<form action="/update-profile" method="POST"> <input type="hidden" name="csrf_token" value="ランダムなトークン文字列"> <input type="text" name="username"> <button type="submit">送信</button> </form>サーバー側では、この
csrf_token の値と、セッションやCookieなどに保存された値を照合し、一致しなければリクエストを拒否します。このようなトークンの発行・検証の仕組みは、自前で実装することも可能ですが、実際には主要なWebフレームワークにCSRF対策機能が組み込まれているため、多くのケースで独自実装は不要です。
※ Webフレームワークとは？
Webアプリの開発を効率化するための“土台となる仕組み”のことで、フォーム送信・認証・画面表示などの基本機能が最初から備わっています。
たとえば Laravel、Django、Rails などが有名で、CSRF対策も標準で組み込まれているため、安全なフォームを簡単に実装できます。
以下に代表的な機能例をまとめました。
| フレームワーク | CSRF保護機能 |
|---|---|
| Laravel | CSRFトークンの自動生成と @csrf Bladeディレクティブ |
| Ruby on Rails | protect_from_forgery 機能 |
| Django | {% csrf_token %} テンプレートタグ |
| Spring | CsrfFilter、csrfトークンタグ |
| ASP.NET MVC | @Html.AntiForgeryToken() ヘルパー |
詳しい使い方や設定方法は、各フレームワークの公式ドキュメントをご参照ください。
参照：OWASP「CSRF対策チートシート」
参照：Django公式「CSRFミドルウェア解説」
Refererヘッダをチェックする
Referer（リファラー）ヘッダーの確認は、CSRF対策の中でも比較的シンプルに導入できる方法のひとつです。HTTPリクエストには通常、「このリクエストはどのページから送られてきたか」を示す情報（Refererヘッダー）が含まれています。
このヘッダーを利用して、自分のサイトからのリクエストかどうかを確認することで、外部サイトからの不正なアクセスをある程度ブロックできます。
PHPでのRefererチェック例
以下は、許可されたドメインからのアクセスのみを受け付ける簡単な例です。
<?php
$referer = $_SERVER['HTTP_REFERER'] ?? '';
$allowed_domains = ['example.com', 'sub.example.com'];
$is_valid_referer = false;
foreach ($allowed_domains as $domain) {
if (strpos($referer, $domain) !== false) {
$is_valid_referer = true;
break;
}
}
if (!$is_valid_referer) {
die('不正なリクエスト発生元です');
}
// 正当なリクエストの場合は処理を続行
?>
このようなチェックを入れることで、外部サイト経由での不正なリクエストを一部防ぐことができます。
Refererチェックの注意点
ただし、この方法には以下のような制限や注意点もあります。- ユーザー側でRefererの送信を無効にしていると使えない
（プライバシー設定や拡張機能でRefererヘッダーが送られない場合があります） - HTTPS → HTTP のリクエストではRefererが自動的に省略される
（セキュリティ上の仕様です） - Refererは改ざんされる可能性がある
（完全に信頼できる情報ではないため、「補助的な対策」として考えるべきです）
あくまで「防御レイヤーの一部」として活用するのがベストです。
SameSite属性を活用する
SameSite（セイムサイト）属性は、外部サイトからのリクエストでCookieが自動送信されるのを防ぐ仕組みです。これを使うことで、CSRF攻撃に対する強力な防御層をブラウザ側で追加できます。
※ SameSite属性とは？
通常、ログイン状態などを保持する「Cookie（クッキー）」は、外部サイトからのリクエストでも自動的に送られてしまうことがあります。
SameSite属性を使うと、「どこからのアクセスならCookieを送ってもいいか？」をブラウザ側でコントロールできるようになります。
たとえば、「自分のサイト内からのアクセスだけ許可する」と設定すれば、外部サイトからの不正なアクセスではログイン状態が共有されないため、CSRFの被害を防ぎやすくなります。
SameSite属性の3つの設定値
SameSiteには、次の3種類の動作モードがあります。| SameSiteの値 | 動作の概要 |
|---|---|
| Strict | 完全に同一サイトからのリクエストのみCookieを送信。最も安全だが、一部の機能に影響が出る可能性あり。 |
| Lax | 同一サイトのリクエストに加え、「リンククリック」「GETによる画面遷移」でもCookieが送られる。多くの用途に適したバランス型。 |
| None | クロスサイトリクエストでもCookieを送信。ただし、Secure属性（HTTPS通信のみ）との併用が必須。 |
SameSite属性の設定例（PHP）
以下は、PHPでCookieを設定するときに SameSite 属性を指定する例です。
<?php
setcookie(
'session_id',
'1234567890abcdef',
[
'expires' => time() + 3600,
'path' => '/',
'domain' => 'example.com',
'secure' => true,
'httponly' => true,
'samesite' => 'Lax' // SameSite属性をLaxに設定
]
);
?>
補足：最近のブラウザの挙動
多くのモダンブラウザでは、SameSite属性が明示されていない場合のデフォルト値が「Lax」になっています。そのため、開発者が何もしなくても、最低限のCSRF対策が自動的に適用されるようになってきています。
※「モダンブラウザ」とは、Google ChromeやMicrosoft Edge、Firefox、Safariなど、最新のWeb標準に対応したブラウザのことです。
多くのモダンブラウザでは、SameSite属性が明示されていない場合でも「Lax」が自動的に適用され、基本的なCSRF対策が働くようになっています。
注意点
SameSite属性は強力な防御機能ですが、これだけでCSRFを完全に防げるわけではありません。特に、JavaScriptを介したリクエストや、認証トークンの扱いが別の仕組みになっているケースでは不十分です。
CSRFトークンの導入やRefererヘッダーのチェックなど、他の防御策と組み合わせて使用することが推奨されます。
ユーザー側も注意を払う
CSRF対策は、Webサイト運営者の責任だけでなく、ユーザー自身の行動によってもリスクを下げることができます。セキュリティ意識の高い行動を取ることで、不正なアクセスの被害に遭うリスクを減らすことが可能です。
ユーザーができるCSRF対策の行動例
- 重要なサイトは、利用後に必ずログアウトする
特にネットバンキングや会員制サイトでは、ログイン状態のまま放置しないようにしましょう。 - プライベートブラウジングや複数ブラウザの使い分け
通常のWeb閲覧と、個人情報を扱うサイトは分けて利用するのが理想です。 - 不審なリンクを開かない
メールやSNSで届いた怪しいリンクは、安易にクリックせずにURLを確認する習慣を。 - ブラウザを常に最新の状態に保つ
モダンブラウザではセキュリティ機能（SameSite属性など）が日々強化されています。 - セキュリティ拡張機能を利用する
例：NoScriptやuBlock Originなどで、不審なスクリプトの実行を防げます。
Webサイト運営者は、こうしたユーザー行動を促すことも大切です。
ヘルプページでの案内や、ログイン後の注意喚起、定期的なセキュリティ情報の提供など、ユーザーの意識向上につながる工夫を取り入れていきましょう。
まとめ：CSRF対策と共に、サイバー保険を
技術的なCSRF対策を講じることは非常に重要ですが、万が一の被害発生に備える視点も欠かせません。 事故発生後の損害賠償や対応費用に備え、サイバー保険の一括見積で、補償内容を比較・検討しておくことをおすすめします。 特にWebサービス等を提供している企業は、インシデントが起こった際のリスク分散が重要となります。▶ サイバー保険 一括見積はこちら（無料）
当サイトを運営する「ファーストプレイス」では、
大手5社のサイバー保険の保険料を、無料で一括比較・見積りいただけます。
- 東京海上日動火災保険株式会社
- 三井住友海上火災保険株式会社
- 損害保険ジャパン株式会社
- あいおいニッセイ同和損害保険株式会社
- AIG損害保険株式会社
ECサイトやWebサービスを提供している企業様は、IT業務を提供する企業様向けの「IT業務用サイバー保険一括見積サイト」もご検討ください。
参照：IPA「安全なウェブサイトの作り方 – 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）」
参照：JPCERT「クロスサイトリクエストフォー ジェリ(CSRF)とその対策」
