CSRF攻撃とは？仕組み・脅威・対策を徹底解説【実例付き】

CSRF攻撃は、ユーザーの知らないうちにウェブサイトでブラウザーに操作を実行させる手法です。攻撃者はパスワードを知らなくても、セッションを乗っ取らなくても、あるいはアカウントへ直接アクセスしなくても、すでにブラウザーが「ユーザーは認証済み」とみなしていることを悪用します。

CSRFは「Cross-Site Request Forgery（クロスサイト・リクエスト・フォージェリ）」の略で、日本語では「クロスサイトリクエストフォージェリ」や「サイト間リクエスト偽造」と呼ばれます。悪意あるページやリンクが他のサイトへのリクエストを発生させ、ブラウザーが自動的に認証データ（例：セッションクッキー）を付与することで成り立ちます。もしサーバーがリクエストの出所を確認しなければ、その操作をアカウントの持ち主のものと誤認してしまうのです。

とくに設定変更やメールアドレス変更、アカウント情報の更新などデータを変更する操作がCSRF攻撃の標的になりやすいです。なぜこのような攻撃が可能なのか、cookieがどのように関わっているのか、そしてCSRFトークンがどのようにして本物のリクエストと偽のリクエストを区別するのか、詳しく見ていきましょう。

CSRF攻撃とは？なぜ発生するのか

CSRFを簡単に説明

CSRF攻撃は、ユーザーがすでにサイトにログインしていて、ブラウザーがそのセッション情報を保存しているときに成立します。たとえば、ECサイトや社内パネルなどにログインしたまま別のページを閲覧している場合、そのセッション中であれば、ブラウザーは自動的にリクエストを承認します。

この状態でユーザーが細工されたページを開いたり、悪意あるリンクをクリックしたり、外部サイトから埋め込まれた要素を読み込んだりすると、ユーザーがログインしているサービスへ勝手にリクエストが送信される場合があります。ユーザー自身はその動作に気付かないこともあります。

問題となるのは、サーバーが「有効なセッションがあるか」だけを確認し、リクエストが本当にユーザー自身から送られたものかどうかを確かめないケースです。簡単に言えば、ユーザーがアカウントにログインしている状態で外部ページを訪れ、そのページが標的サービスへのリクエストを発生させてしまうのです。

Cross-Site Request Forgeryの意味

CSRF（Cross-Site Request Forgery）は「サイト間リクエスト偽造」と訳されます。つまり、「あるサイトで生成されたリクエストが、別のサイトへログイン済みユーザーの名義で送信される」という攻撃です。

CSRF攻撃（試み）とCSRF脆弱性（ウェブアプリケーションの不備）は別物です。攻撃者がブラウザーを操作させようとするのが前者、サーバー側でリクエストの正当性確認を怠る設計ミスが後者です。

ブラウザー自体は本来の仕様どおりに動作します。ドメインに紐付いたcookieなどのデータを自動送信するのが通常の挙動です。問題は、有効なセッションがある＝ユーザーの意図した操作だとアプリケーションが誤って判断する点にあります。

このため、CSRFはパスワード窃取やアカウント乗っ取りがなくても成立します。攻撃者は既存の認証情報を利用し、ユーザーの代理で実行可能な操作を仕掛けるのです。

CSRF攻撃の仕組み: 悪意あるページからユーザー名義のリクエストまで

なぜブラウザーは自動でcookieを送信するのか

ユーザーがログインすると、サイトはセッションを発行し、それをcookieでブラウザーに保存します。以降、同じドメインへのアクセス時、cookieは自動的にリクエストに添付されるため、毎回ログインし直す必要がありません。

この仕組みを突くのがCSRF攻撃です。外部ページが、すでにユーザーが認証されたサイトへのリクエストを発生させると、条件によってはブラウザーがセッションクッキーを付与してしまい、サーバーは正規ユーザーからの操作と誤解することがあります。

重要なのは、「正しいcookieがある＝本当にユーザーが操作した証拠ではない」という点です。追加の確認がなければ、攻撃者がこの認証と意図確認のギャップを悪用できてしまいます。

CSRF攻撃の例

たとえば、認証ユーザーがアカウント設定を変更できるサービスがあるとします。もしサーバーが「有効なセッションがあるか」だけで変更リクエストを受け付けていれば、外部サイトから同じリクエストを発生させることが理論上可能です。

ユーザーは外部サイトを開いただけで、バックグラウンドでブラウザーが標的サービスにアクセスします。サーバーから見れば、正規ユーザー自身が送ったリクエストに見えてしまいます。

このとき攻撃者はサーバーのレスポンスやアカウント詳細を取得する必要はありません。CSRFの目的は「他人のデータを読む」ことではなく、「犠牲者の名義で操作させる」ことです。

特に危険な操作例

• 連絡先情報やセキュリティ設定の変更
• アカウント情報・プロフィールの更新
• 管理パネルでの操作（権限によっては甚大な被害）

こうした操作に追加の確認を設けず、リクエスト受信後すぐに実行してしまうと、CSRFのリスクは非常に高まります。管理者アカウントで発生した場合、被害の規模がさらに拡大します。

そのため、重要な操作ではセッションがあるだけでなく、正規のインターフェース経由かどうかを確認する仕組みが必要です。

CSRFトークン：本物のリクエストを見分ける仕組み

CSRFトークンとは？

CSRFトークンは、サーバーが機密性の高いリクエストごとに発行し、対象ユーザー・セッション・フォームごとにページへ埋め込む「追加の検証値」です。ユーザーがサイトの正規インターフェースでフォーム送信や設定変更を行うと、トークンも一緒にサーバーへ送信されます。サーバーは受け取ったトークンが期待した値かどうかを確認し、一致した場合のみ処理を実行します。

これにより、有効なセッションだけでは不十分になります。正しいCSRFトークンがなければ、たとえcookieが自動付与されてもリクエストは拒否されます。

攻撃者が正しいトークンを送れない理由

外部サイトからは、他ドメインのページ内容（CSRFトークンを含む）へ自由にアクセスできません。つまり、リクエストを発生させることはできても、本物のトークンを取得・利用するのは通常困難です。

これはcookieとの大きな違いです。cookieはブラウザーが自動で送信しますが、CSRFトークンはアプリケーションが明示的にリクエストへ含める必要があります。

トークン値が予測不能でサーバーが確実に検証していれば、たとえユーザーが認証済みでもリクエストの偽装は大幅に困難になります。

その他のCSRF対策

• SameSite属性付きcookie：サイト間リクエスト時のcookie送信を制限し、外部ページからの攻撃を抑制
• Origin/Refererヘッダー検査：リクエストの送信元を検証し、正規ページからの操作かどうかを確認
• 再認証やワンタイムコード：特に重要な操作時、追加で本人確認を要求し、セッションやリクエスト偽装だけでは突破できないようにする

これらを複数組み合わせることで、CSRFに対する防御力を高めることができます。

CSRFとXSSの違い

CSRFはサイトの「ブラウザーへの信頼」を悪用

CSRF攻撃では、攻撃者が「すでに存在する認証情報」を利用し、ブラウザーが自動でセッションクッキーを添付する仕様を突きます。攻撃の発端は、必ずしも標的サイト内とは限らず、外部ページから始まるのが特徴です。

XSSは「ユーザーのサイトへの信頼」を悪用

XSS（クロスサイトスクリプティング）は、サイトに悪意のあるJavaScriptが埋め込まれ、ページ上で実行される脆弱性です。スクリプトが動作すると、ユーザーの操作やデータを盗み取ったり、ページ内容を書き換えたり、ユーザー名義でリクエストを送信することもあります。

CSRFではページ内容の取得は困難ですが、XSSでは攻撃者のスクリプトが信頼されたページ内で動作するため、より広範囲な悪用が可能です。

なぜ片方の対策だけでは不十分なのか

CSRFトークンは外部サイトからのリクエスト偽装防止に有効ですが、XSSには無力です。XSSによってページ上でJavaScriptが動けば、そのスクリプトがCSRFトークンを読み取って悪用する恐れもあります。

逆に、XSS対策（入力値のエスケープやContent Security Policyなど）だけではCSRF攻撃は防げません。両者は異なる脅威のため、それぞれに専用の対策が必要です。

CSRF攻撃からサイトを守る方法

データを変更する全リクエストを検証

CSRF対策の基本は、ウェブアプリケーションの正しい設計です。ユーザーデータやシステム状態を変えるリクエストは、「有効なセッションがあるだけ」で受け付けてはいけません。

• データ取得にはGETメソッドを使用する
• 設定変更やデータ削除などの操作は、POST・PUT・PATCH・DELETEなどのメソッドと追加検証を組み合わせる

HTTPメソッドを正しく使うだけでなく、リクエストの出所や検証値（例：CSRFトークン）の確認も欠かせません。

CSRFトークンとSameSite cookieの活用

最も効果的な対策のひとつが、CSRFトークンの導入です。サーバーが予測困難な値を生成し、リクエストごとに検証します。外部ページからは正しいトークンの取得が難しいため、セッションが有効でも偽装リクエストは拒否されます。

また、cookieのSameSite属性を利用することで、外部サイト発のリクエストにcookieを自動送信しないよう設定し、認証情報の悪用リスクを減らせます。

CSRFトークンとSameSite属性は相互補完的な役割を果たします。トークンはリクエストそのものの正当性を、SameSiteはcookieの送信制御を担います。

CSRFは代表的なウェブ脆弱性のひとつですが、SQLインジェクションのように、攻撃者がユーザーのブラウザーではなく、アプリケーションのデータベース操作自体を狙う場合もあります。詳しくは、下記の解説をご覧ください。

SQLインジェクションの仕組みと対策について詳しく読む

重要操作には追加の本人確認を

パスワード変更や認証情報の再設定、権限管理などの重要な操作では、CSRFトークン検証だけでは不十分な場合があります。再度のパスワード入力やワンタイムコード、専用の確認手続きなどを組み合わせることで、偶発的または偽装リクエストによる重大な変更を防げます。

OriginやRefererヘッダーの検査も有効な補助策ですが、単独での利用は十分な防御策とはなりません。HTTPメソッドの適切な運用、CSRFトークン、SameSite cookie、リクエスト出所の検証、重要操作時の追加認証など、多層的な対策が不可欠です。

まとめ

CSRF攻撃はパスワードの窃取ではなく、「サイトが認証済みブラウザーに対して持つ信頼」を悪用します。ユーザーがログインしているだけでサーバーがすべての操作を信頼してしまうと、外部ページから代理リクエストが発生し得ます。

主要な防御策はCSRFトークンによるリクエストの正当性確認です。加えて、SameSite cookie、OriginやRefererの検証、正しいHTTPメソッドの運用、重要操作時の再認証などを組み合わせることで、リスクを大幅に低減できます。

開発者にとって大事なのは、「有効なセッションがある＝ユーザーが意図して操作した」ではないことを理解し、データ変更操作には必ず追加の正当性確認を設けることです。