CSRF（クロスサイトリクエストフォージェリ）とは？
CSRFの正式名称や読み方などの基礎知識に加え、なぜ攻撃が成立してしまうのかという仕組みや、攻撃完了までの具体的な流れについて詳しく解説します。
CSRFとは？
CSRF（正式名称：Cross-Site Request Forgeries）は、「CSRF（シーサーフ）」や「XSRF」とも呼ばれ、直訳すると「サイト横断的なリクエストの偽造」を意味します。
これは、ユーザーが攻撃者の用意した「罠サイト」にアクセスすることで、ログイン中のWebサイトに対し、本人の許可なくコマンド（送金や投稿など）が強制的に送信されてしまう脆弱性です。
例えば、ネットバンキングにログイン中の状態で罠サイトを踏んだ際、裏側で勝手に「送金リクエスト」が送信されるケースが挙げられます。Webサイト側が「その操作が本当にユーザー本人の意思によるものか」を正しく検証できない場合、攻撃者のなりすまし操作が成立してしまいます。
CSRF攻撃の仕組みと攻撃成立までの流れ
CSRF攻撃がどのように成立するのか、具体的な流れで見ていきましょう。 攻撃のポイントは、Webアプリケーションが利用者を識別するために用いるCookieなど「セッションID」の仕組みを悪用する点にあります。
IPA（独立行政法人情報処理推進機構）が公開しているモデルケースを基に、攻撃成立までのステップを解説します。
- ログインして利用開始
利用者がWebサイト（例：銀行やECサイト）にログインします。この時、ブラウザには利用者を識別するための「Cookie（クッキー）」が保存され、ログイン状態が維持されます。 - 攻撃者が偽メールなどで誘導
攻撃者は、Webサイトに対して不正な命令（送金や購入など）を送るよう仕組んだ「罠サイト」を用意し、巧妙な偽メールやSNSなどを通じて利用者をそこへ誘導します。 - うっかりアクセス
利用者はそれが罠サイトだとは気づかず、ログイン状態のまま誘導されたリンクをクリックし、罠サイトへアクセスしてしまいます。 - 勝手に命令を送信・実行
罠サイトにアクセスした瞬間、利用者のブラウザからWebサイトに向けて、攻撃者が仕込んだ命令（リクエスト）が勝手に送信されます。
この際、ブラウザに保存されていた「Cookie」も一緒に送信されてしまうため、Webサイト側はこれを「本人による正規の操作」と勘違いして受け入れ、送金や購入などの処理を実行してしまいます。
CSRFとXSS（クロスサイトスクリプティング）との違いは？
CSRFとよく混同される脆弱性に、XSS（クロスサイトスクリプティング）があります。 どちらもWebブラウザ経由で攻撃が行われますが、攻撃の仕組みや狙いは明確に異なります。
ここでは、この2つの脆弱性の根本的な違いと、両者が組み合わさった場合の危険性についても解説します。
CSRFとXSS攻撃の主体・目的・影響の違いとは？
CSRFとXSSの決定的な違いは、攻撃の起点となる「仕組み」にあります。
CSRF（クロスサイトリクエストフォージェリ） ユーザーの意図しないリクエストを利用する攻撃です。 Webアプリケーションが、ログイン中のユーザーからのリクエストを「正しいもの」として無条件に信頼してしまう性質を悪用します。
XSS（クロスサイトスクリプティング） Webサイトに不正なスクリプトを埋め込む攻撃です。 ユーザーがWebサイト（およびそこに表示される内容）を信頼していることを悪用し、ブラウザ上で悪意あるプログラムを実行させます。
それぞれの違いを整理すると、以下のようになります。
| 項目 | CSRF （クロスサイトリクエストフォージェリ） | XSS （クロスサイトスクリプティング） |
| 攻撃概要 | ユーザーの意図しないリクエストを利用する攻撃 | Webサイトに不正なスクリプトを埋め込む攻撃 |
| 攻撃の主体 | ユーザーのブラウザ | |
| 攻撃者の狙い | ユーザーになりすまして「処理」を実行させること （ユーザー自身が無自覚に購入・退会・設定変更などのリクエストを送信してしまう） | ユーザーのブラウザ上で「不正なスクリプト」を実行させること （cookieの盗取、偽の入力フォーム表示、ウィルスダウンロードサイトへの誘導など） |
| 主な影響 | 不正送金、設定変更、不正購入など、サーバ側の状態を変化させること | Cookie（セッションID）の盗取、偽ログイン画面の表示（フィッシング）、ウイルス感染など |
CSRFは「勝手に操作される攻撃」であり、XSSは「情報を盗まれたり、画面を改ざんされたりする攻撃」といえます。
CSRF対策が破られる？XSS脆弱性が引き起こす複合リスク
注意が必要なのは、これらは決して独立したリスクではないという点です。もしWebアプリケーションにXSS脆弱性が存在する場合、CSRF対策を行っていても突破されてしまうという「複合的なリスク」が発生します。
通常、CSRF対策には「トークン」と呼ばれる仕組みが用いられます。これは、送信されたリクエストが「偽のリクエスト」ではないことを証明するための、いわば一時的な「身分証明書」のようなものです。
しかし、XSSによって攻撃者がページ内で任意のスクリプトを実行できる状態にあると、この対策用トークンさえもスクリプトによって盗み取られてしまう可能性があります。
トークンが漏えいすれば、攻撃者はそれを悪用して「正規のリクエスト」に見せかけることができるため、結果的にCSRF攻撃も防げなくなります。
具体的な対策については後述しますが、XSS脆弱性を放置することは、CSRF対策をも無効化するリスクがある点を理解し、両方に対して適切な対策を講じることが重要です。
CSRF攻撃のリスクと対象とは？
CSRF攻撃を受けると、ユーザーだけでなくWebサービス運営企業も信用失墜や損害賠償といった大きなダメージを負うことになります。代表的な例を解説します。
CSRFによって引き起こされる主な被害
CSRFを放置すると、ログイン中の利用者の権限が悪用され、攻撃者による「なりすまし」操作を許してしまいます。
具体的な被害はサービスの性質によって異なりますが、金銭的な被害だけでなく、利用者が知らぬ間に犯罪の片棒を担がされるような社会的被害に発展するケースもあります。
＜被害例＞
- ECサイト・Webサービス
・意図しない商品の購入（金銭的被害）
・登録情報の書き換え、退会処理の勝手な実行 - SNS・掲示板
・犯罪予告や誹謗中傷など、意図しない書き込みの投稿
・※利用者が意図せず「加害者」として扱われてしまうリスクがあります。 - Webメール・管理画面
・メール転送設定の変更による機密情報の漏えい
・パスワードの勝手な変更によるアカウントの乗っ取り
特にCSRF攻撃は、ユーザーが操作完了画面や購入完了メールを見るまで被害に気づかないケースが多く、発見が遅れる傾向にあります。
特に注意が必要なWebサイトの特徴
CSRFは、ブラウザがCookieを自動送信する仕様を悪用するため、「Cookieを使ってログイン状態（セッション）を管理しているWebサイト」は対象となり得ます。
中でも、以下のような機能を持つサイトは攻撃者の標的になりやすく、被害も深刻化するため、重点的な対策が求められます。
＜CSRF攻撃の標的になりやすいサイト例＞
- Cookieでセッション管理を行っているサイト
- 決済や資産移動が発生するサイト
・ECサイト、ネットバンキング、ポイント交換サイトなど - 重要な情報の変更機能があるサイト
・SNS、会員制サイト（パスワード変更、メールアドレス変更、退会処理など） - 管理者権限を持つサイト
・CMSの管理画面、社内ポータル、ルーターの設定画面など
・※外部からアクセスできない社内システムでも、管理者が罠サイトを踏むことで攻撃が成立してしまいます。 - 重要な操作時に「再認証」がないサイト
・最終的な処理（送金や退会ボタン押下など）の直前に、パスワード再入力などのチェックがない場合、攻撃が素通りしてしまいます。
CSRFの有効なセキュリティ対策とは
CSRFを防ぐためには、Webサイトを利用するユーザー側の注意も必要ですが、根本的な解決にはWebアプリケーション開発側での実装による対策が不可欠です。
利用者側（ユーザー）ができる対策
ユーザーができる自衛策には限りがありますが、以下を心がけることでリスクを低減できます。
- Webサービスの使用後は、必ず「ログアウト」を行う。
- 怪しいメールのリンクや、不審なWebサイトを開かない。
- ブラウザのセキュリティ機能を最新の状態に保つ。
Webサイト制作側（開発者）ができる主な対策
Webサイト開発者が実装すべき対策の基本は、送られてきたリクエストが「本当に自サイトの正規ページから送信されたものか」を厳密に検証する仕組みを導入することです。 単一の対策だけでなく、複数を組み合わせることで安全性を高めることが推奨されます。
- CSRFトークン（ワンタイムトークン）の実装
最も一般的かつ強力な対策です。サーバー側で推測困難な乱数（トークン）を生成し、フォームのhiddenフィールドなどに埋め込みます。
リクエスト送信時にこのトークンを照合し、一致しない場合は処理を拒否します。攻撃者はこのトークンを知り得ないため、不正なリクエストを遮断できます。 - SameSite属性の設定
Cookieに SameSite 属性（Strict または Lax）を設定する方法です。
これにより、他サイト（クロスサイト）からのリクエスト時にはCookieが送信されないようブラウザ側で制御できます。
モダンブラウザでは標準的な対策となりつつあります。 - パスワード再入力（再認証）の実装
送金、パスワード変更、退会処理など、特に重要な操作の直前に、再度パスワード入力を求める仕様にします。もしCSRF攻撃を受けても、攻撃者はユーザーのパスワードを知らないため、最終的な処理の実行を物理的に阻止できます。 - Referer（リファラ）のチェック
HTTPヘッダのReferer（リンク元情報）を確認し、許可されたドメイン以外からのリクエストを拒否する方法です。ただし、セキュリティソフトの影響でRefererが送信されない場合や、偽装されるリスクもあるため、あくまで補助的な対策として用います。 - 脆弱性診断の実施
上記のような対策を実装しても、設定ミスやフレームワークの仕様変更により、意図せず脆弱性が残ってしまうことがあります。
定期的にセキュリティ診断を実施し、第三者の視点で「正しく対策できているか」を検証することが、事故を防ぐ最後の砦となります。
CSRF脆弱性が残る「対策の落とし穴」
現代のWebフレームワーク（Laravel, Rails, Djangoなど）には、標準でCSRF対策機能が備わっていることが多くなっています。 しかし、実装時の設定ミスや独自のカスタマイズにより、以下のようなケースで脆弱性が残ってしまうことがあります。
- 設定の無効化や漏れ
フレームワークのバージョンアップ時に設定が無効になっていたり、API実装時にCSRF保護を意図的に「除外設定」にしてそのまま放置されたりするケース。 - 重要な処理での検証漏れ
退会処理や設定変更などを誤って「GETリクエスト」で実装してしまい、トークン検証の対象から漏れてしまうケース。 - トークンの推測可能性（ランダム性の不足）
トークンに使用する文字列のランダム性が低く、攻撃者に次のトークンを予測されて突破されてしまうケース。 - Referer（リファラ）検証のみに依存
リクエスト元のRefererヘッダを確認するだけの対策は、ブラウザの仕様やセキュリティソフトの影響、他の脆弱性によって回避される可能性があり、単独では不十分です。 - 検証ロジックの不備
実装ミスにより、トークンが空の値でもチェックを通過してしまうケース。
「フレームワークを使っているから安心」と過信せず、正しく機能しているか確認することが重要です。
脆弱性診断の重要性
セキュリティ対策としてWAF（Web Application Firewall）を導入している企業も多いですが、CSRF対策においてはそれだけでは不十分な場合があります。
CSRFは、形式上は「正規のリクエスト」に見せかけて攻撃を行うため、シグネチャ（攻撃パターン）検知を主とするWAFでは、アプリケーション固有の仕様の不備（ロジックの穴）を完全に防ぎきれない可能性があるためです。
▼WAFについて詳しくはこちら
【情シス担当者必見】WAFの基本機能と防げる攻撃を徹底解説！
根本的な対策は、前述したトークンやSameSite属性などの「アプリケーション側の実装」になります。しかし、特に大規模なWebサイトほど機能が複雑になり、すべてのリクエスト経路でトークン検証が正しく行われているかを、開発チームだけで完璧にテストし続けるのは困難です。
抜け漏れがないかを確認するには、専門家による「脆弱性診断」を活用することが非常に有効です。ツールによる網羅的なスキャンに加え、セキュリティエンジニアによる手動診断を組み合わせることで、ツールだけでは見抜けない論理的な欠陥や設定ミスを発見することができます。第三者の視点を取り入れることは、Webサイトの安全性を確実に担保する最も有効な手段といえます。
脆弱性診断（セキュリティ診断）なら
「サイバーセキュリティクラウド脆弱性診断サービス」
サイバーセキュリティクラウドの脆弱性診断サービスは、こうした攻撃リスクからお客様のWebサイトを守るため、セキュリティ専門家による手動診断と診断ツールを組み合わせた「ハイブリッド診断」を提供しています。
本記事で解説したCSRFやXSSはもちろん、セキュリティ業界の国際的な指標であるOWASP（Open Web Application Security Project）の主要な脆弱性項目を網羅しています。
「自社のCSRF対策は本当に万全か？」「XSSやその他の脆弱性が残っていないか？」を確実に把握したいご担当者様は、ぜひ下記より詳しいサービス資料をダウンロードしてご確認ください。
- ハイブリッド診断で徹底チェック： ツールでは検知が難しい、複雑なロジックに潜むCSRF脆弱性も専門家が丁寧に診断します。
- わかりやすい診断報告書： 検出された脆弱性は、危険度ランク別に分類し、再現手順や具体的な修正方法まで詳細に解説します。開発担当者がすぐに修正作業に着手できる実践的な内容です。
- 無料の再診断（修正確認）： Webアプリケーション診断サービスは、報告書提出後1ヶ月以内であれば、修正箇所の再診断を無料で実施します。対策が正しく機能しているかを確認できるため、安心してリリースを迎えられます。
