Webアプリケーションの利用が日常の一部となる中で、私たちが意識せずに利用している「便利機能」が、時にはセキュリティ上の大きな穴となることがあります。
例えば、SNSやショッピングサイトに一度ログインすると、しばらくの間はパスワードを入力しなくても使い続けられます。これは、ブラウザとサーバーの間で「信頼関係」が維持されているためです。しかし、この信頼関係を悪用し、利用者の意図しない操作を勝手に行わせる攻撃手法が存在します。それがクロスサイトリクエストフォージェリ(CSRF:Cross-Site Request Forgery)です。
「掲示板に勝手に犯罪予告を書き込まれた」「オンラインバンキングから身に覚えのない送金がされた」「アカウントのパスワードを知らない間に変更された」。これらはすべて、CSRFによって引き起こされる可能性がある被害です。攻撃者はあなたのパスワードを盗むのではなく、あなた自身のブラウザが持つ「権限」を乗っ取って、あなたの手で犯行を行わせるのです。
本記事では、CSRFがなぜ発生するのか、その攻撃フローを詳細に解き明かし、開発者や運用者が実装すべき「鉄壁の対策」について解説します。仕組みを正しく理解し、堅牢なWebサイト構築への第一歩を踏み出しましょう。
CSRF(クロスサイトリクエストフォージェリ)の攻撃フローと仕組み
CSRFを理解するためには、まずWebブラウザとWebサーバーがどのようにして「誰がアクセスしているか」を識別しているかを知る必要があります。そして、その識別方法の隙をどのように攻撃者が突いてくるのか、順を追って見ていきましょう。
Webにおける「セッション管理」の重要性
HTTPというプロトコル(通信の約束事)は、基本的に「ステートレス(状態を持たない)」な通信です。つまり、1回目のアクセスと2回目のアクセスが同じ人によるものなのか、Webサーバー側は標準では判断できません。
これでは、ショッピングサイトで商品をカートに入れた次の瞬間に「あなたは誰ですか?」と聞かれてしまい、買い物ができません。そこで利用されるのがCookie(クッキー)とセッションIDです。
ログインに成功すると、サーバーは「セッションID」という長い文字列を発行し、ブラウザに「これをCookieとして保存しておいてね」と伝えます。以降、ブラウザはそのサイトにアクセスするたびに、自動的にこのCookie(セッションID)をサーバーに送信します。サーバーは送られてきたIDを確認することで、「ああ、先ほどログインしたAさんですね」と認識し、ログイン状態を維持します。
この仕組みは非常に便利ですが、「ブラウザが自動的にCookieを送信する」という特性こそが、CSRFの最大の狙い目となります。
攻撃成立の3要素
CSRF攻撃が成立するためには、以下の3つの要素が揃う必要があります。
- 攻撃者(Attacker):罠サイトを作成し、ユーザーを誘導する悪意ある第三者
- 被害者(Victim):ターゲットとなるWebサイトにログイン中の正規ユーザー
- 脆弱なWebサイト(Target Site):CSRF対策が不十分なWebアプリケーション
重要なのは、被害者がターゲットサイトにログイン中である(セッションが有効である)という点です。ログアウトしている状態であれば、CSRF攻撃は基本的に成立しません。
詳細な攻撃フロー
では、具体的な攻撃の流れをステップバイステップで見ていきましょう。ここでは、対策がされていないSNSサイト「Target-SNS」を例にします。
1. 罠の準備
攻撃者は、自身の用意したWebサイト(罠サイト)や、多くの人が閲覧する掲示板などに、巧妙な仕掛けを施します。この仕掛けとは、「Target-SNS」に対して特定の操作(例:攻撃者をフォローする、攻撃的な投稿をする、退会するなど)を要求するHTTPリクエストを送信させるためのHTMLタグやJavaScriptです。
2. 被害者のログイン
被害者は、普段通り「Target-SNS」にログインし、利用しています。この時、被害者のブラウザには「Target-SNS」へのアクセス権限を示すCookie(セッションID)が保存されています。
3. 罠サイトへの誘導
攻撃者は、フィッシングメールやSNS上の興味を引くリンクなどを使い、ログイン状態の被害者を罠サイトへ誘導します。「面白い画像はこちら」といったリンクを踏ませるのが典型的な手口です。
4. 意図しないリクエストの送信(ここが重要!)
被害者が罠サイトを開いた瞬間、そのページに埋め込まれた仕掛け(スクリプトや画像タグ、自動送信フォームなど)が作動します。これにより、被害者のブラウザから「Target-SNS」に対して、「書き込み」や「設定変更」などのリクエストが勝手に送信されます。
ここで恐ろしいのは、ブラウザの仕様により、「Target-SNS」用のCookieがこのリクエストに自動的に付与されてしまうことです。
5. サーバーによる処理の実行
「Target-SNS」のサーバーは、送られてきたリクエストを受け取ります。リクエストには正しいCookie(セッションID)が付与されているため、サーバーはこれを「被害者本人が自分の意思で送信した正当なリクエスト」と判断してしまいます。
結果として、サーバーはリクエスト通りの処理(攻撃的な投稿の完了やパスワード変更など)を実行します。
6. 被害の発生
被害者の画面上では何も起きていないように見えることもあれば、いつの間にかSNS上に身に覚えのない投稿がされていたり、アカウントが乗っ取られていたりすることになります。
なぜ「クロスサイト」なのか
この攻撃の名称にある「クロスサイト(Cross-Site)」は、攻撃の起点となる「罠サイト(悪意あるサイト)」から、攻撃対象となる「ターゲットサイト(正規のサイト)」へと、異なるサイト(ドメイン)を跨いでリクエストが送信されることに由来します。
通常、JavaScriptによるデータの読み取りなどは「同一生成元ポリシー(Same-Origin Policy)」によって、異なるドメイン間では厳しく制限されています。しかし、HTMLのフォーム送信(POSTリクエスト)や画像の読み込み(GETリクエスト)などは、インターネットの相互接続性を維持するために、ドメインを跨いでも送信自体は許可されているケースが多いのです。CSRFは、この「送信はできてしまう」というWebの基本的な仕様を逆手に取った攻撃と言えます。
CSRFによって引き起こされる具体的な被害
CSRFは単なる悪戯レベルから、金銭的被害、社会的信用の失墜に至るまで、その影響範囲は多岐にわたります。具体的にどのような操作が悪用される危険性があるのか、代表的な例を挙げます。
1. 意図しない決済や送金
ECサイトやネットバンキングにおいて、CSRF対策が不十分な場合、攻撃者が指定した商品を勝手に購入させられたり、攻撃者の口座へ送金処理を行わせられたりする恐れがあります。
ユーザーは「クリックした覚えがない」と主張しても、サーバー上のログには「正規のログインセッションからのリクエスト」として記録されているため、本人の過失ではないことを証明するのが難しくなる場合もあります。この種の被害は、直接的な金銭的損失を生むだけでなく、被害者がサービスへの信頼を完全に失う原因となります。
2. アカウント設定の変更(乗っ取り)
Webサービスの「メールアドレス変更」や「パスワード変更」機能がCSRFのターゲットになると、非常に深刻です。
攻撃者は、被害者のアカウントに登録されているメールアドレスを攻撃者自身のものに変更させるリクエストを送らせます。これが成功すると、パスワードリセットの手続きを攻撃者のメールアドレスで行えるようになり、完全にアカウントを乗っ取ることが可能になります。SNSアカウントであれば個人情報の流出、業務用アカウントであれば企業機密の漏洩につながる危険性があります。
3. SNSや掲示板への書き込み
本人になりすまして、犯罪予告や誹謗中傷、あるいは攻撃サイトへの誘導リンクなどを書き込ませます。
これは「遠隔操作ウイルス」事件などで社会問題となった手法と結果的には似ており、被害者が誤認逮捕されたり、社会的信用を失ったりするリスクがあります。特に、企業の公式アカウントなどが被害に遭った場合、そのブランドイメージへのダメージは計り知れません。書き込みが拡散される前に削除できたとしても、スクリーンショットなどで証拠が残ってしまうこともあり、完全な被害回復は困難です。
4. ルーターやIoT機器の操作
CSRFのターゲットは、インターネット上のWebサイトに限りません。家庭内LANにあるルーターやIoT機器の管理画面も、Webブラウザ経由で操作するものが多く存在します。
もしユーザーがルーターの管理画面にログインしたまま、外部の罠サイトを閲覧してしまうと、CSRFによってルーターのDNS設定を書き換えられるなどの被害に遭う可能性があります。これにより、正規のURLを入力してもフィッシングサイトに誘導されるようになるといった、より高度な攻撃の足掛かりにされてしまいます。また、防犯カメラやスマート家電の設定を勝手に変更されるといった物理的な危険も想定されます。
5. データの削除や改ざん
ブログ記事の削除、データベースのレコード削除、プロフィール情報の改ざんなど、ユーザーが持つ権限で実行可能なあらゆる削除・変更操作がCSRFの対象となります。長年蓄積してきたデータが一瞬で消失するリスクや、改ざんされた情報によって取引先との信頼関係が損なわれるリスクがあります。
CSRFへの3つの鉄壁対策
CSRFはWebの基本的な仕組みを悪用するため、ファイアウォールなどでは防ぎにくい攻撃です。アプリケーションの設計・実装レベルでの対策が必須となります。ここでは、確実性の高い順に3つの対策を紹介します。
対策1:ワンタイムトークン(CSRFトークン)の利用
現在、最も推奨されている根本的な対策です。この手法では、正規のフォームからのリクエストであることを証明するために、合言葉のような「トークン」を使用します。
仕組み
トークンの発行
ユーザーが入力フォーム(送金画面や投稿画面など)を要求した際、サーバーは推測困難なランダムな文字列(トークン)を生成します。このトークンは通常、128ビット以上の長さを持ち、暗号学的に安全な乱数生成器を用いて作成されます。
トークンの埋め込み
サーバーは、このトークンをHTMLの<form>タグ内の隠しフィールド(<input type="hidden">)に埋め込んで、ユーザーに送信します。同時に、サーバー側(セッション内)にもこのトークンを保存しておきます。つまり、トークンはサーバーとユーザーのブラウザの両方に存在する「秘密の合言葉」となるわけです。
トークンの照合
ユーザーがフォームを送信(POST)する際、埋め込まれたトークンも一緒に送信されます。サーバーは、送られてきたトークンと、サーバー側に保存しておいたトークンが一致するかを確認します。一致すれば正規のリクエストとして処理を実行し、不一致であれば攻撃とみなして処理を拒否します。
なぜ防げるのか
攻撃者は罠サイトを作成する際、フォームを送信させるスクリプトを書くことはできますが、「現在、被害者のセッションに発行されている正しいトークン」を知ることはできません。
なぜなら、トークンは被害者がフォームページを表示した時にのみ生成され、そのHTML内に埋め込まれるものだからです。攻撃者の罠サイトからは、被害者のブラウザが保持している正規サイトのHTMLを読み取ることができません(同一生成元ポリシーにより制限されている)。したがって、罠サイト経由で送信されたリクエストには正しいトークンが含まれておらず(あるいは空のままで)、サーバーは照合に失敗してリクエストを拒否することができます。
対策2:SameSite属性の活用
Cookieには、そのCookieがどのような状況で送信されるかを制御するSameSiteという属性があります。これを適切に設定することで、ブラウザレベルでCSRFを防ぐことが可能です。
SameSite=Strict
他サイト(クロスサイト)からのリクエストには、一切Cookieを送信しません。最も安全ですが、別サイトのリンクから遷移してきた場合でもログイン状態が維持されない(再ログインが必要になる)など、利便性が大きく低下する可能性があります。機密性の非常に高いシステム(銀行の管理画面など)では検討の価値があります。
SameSite=Lax
他サイトからのリクエストでも、安全なトップレベルナビゲーション(リンクをクリックして画面遷移するようなGETリクエスト)の場合のみCookieを送信します。フォームのPOST送信や、画像読み込みなどの裏側でのリクエストにはCookieを送信しません。
現在の多くのブラウザでは、デフォルトでこのLaxが適用される傾向にありますが、明示的に設定することが推奨されます。一般的なWebサービスにおいては、セキュリティと利便性のバランスが最も優れた選択肢です。
SameSite=None
従来通り、クロスサイトのリクエストでも常にCookieを送信します。これを設定する場合、Secure属性(HTTPS通信)が必須となります。埋め込みコンテンツ(iframe内のサービスなど)で使用する場合に必要となりますが、CSRF対策の観点では避けるべき設定です。
SameSite=Laxを設定することで、一般的なCSRF攻撃の多く(POST送信を強制するもの)を防ぐことができます。ただし、GETリクエストで重要な処理を行ってしまうような不適切な実装をしている場合は、Laxでも防げない場合があるため注意が必要です。
対策3:RefererやOriginヘッダの検証
HTTPリクエストヘッダに含まれるReferer(どのページから遷移してきたか)やOrigin(どのドメインから送信されたか)を確認し、正しいドメインからのリクエストであるかをチェックする方法です。
例えば、Originがhttps://target-site.comであれば許可し、https://evil-trap-site.comであれば拒否します。実装は比較的シンプルで、既存のアプリケーションにも追加しやすいというメリットがあります。
注意点
この方法はあくまで補助的な対策として考えるべきです。なぜなら、プライバシー保護の観点からブラウザやセキュリティソフトの設定でRefererを送信しないようにしているユーザーがいるからです。その場合、正規のユーザーも利用できなくなってしまいます。
また、特定の条件下ではヘッダが偽装されたり、送信されなかったりするケースも稀に存在するため、トークン対策と併用するのが望ましいでしょう。単独での使用は推奨されませんが、多層防御の一部としては有効です。
重要な処理における「再認証」
対策というよりは、セキュリティレベルを高める設計思想ですが、重要な処理(パスワード変更、送金、高額購入など)の直前に、再度パスワード入力を求めることも非常に有効です。
CSRF攻撃は、あくまで「ログイン済みのセッション」を悪用するものですが、攻撃者は被害者の「パスワード」そのものを知っているわけではありません。処理の直前でパスワード入力を求められれば、攻撃者が自動的に処理を完了させることは不可能になります。ユーザー体験としては若干の手間が増えますが、重要な操作を保護するためには効果的な方法です。
間違いやすいCSRFとXSS(クロスサイトスクリプティング)の違い
CSRFとよく混同されるのが、XSS(クロスサイトスクリプティング)です。名前は似ていますが、攻撃の原理と狙いは明確に異なります。
XSS(クロスサイトスクリプティング)
- 原理:Webページ内に悪意あるスクリプト(JavaScript)を埋め込み、閲覧者のブラウザ上で実行させる攻撃
- できること:Cookieの盗取(セッションハイジャック)、偽のログイン画面の表示、ブラウザの完全な制御など
- 特徴:攻撃者が作成したスクリプトが、被害者のブラウザ上で動く
XSSでは、攻撃者のコードが被害者側で実行されるため、Cookieなどの機密情報を直接読み取ることができます。つまり、「情報を盗む」ことが主な目的となります。
CSRF(クロスサイトリクエストフォージェリ)
- 原理:Webサイトがブラウザを信頼しすぎることを利用し、意図しないリクエストを送信させる攻撃
- できること:不正な書き込み、購入、退会、設定変更など、そのユーザー権限で可能な操作
- 特徴:攻撃者はスクリプトを被害者のブラウザ上で実行させるのではなく、被害者のブラウザを「踏み台」にしてサーバーへ指令を送る
CSRFでは、攻撃者は情報を直接読み取ることはできません。しかし、被害者の権限で「操作を実行させる」ことができます。つまり、「不正な行動をさせる」ことが主な目的となります。
複合的な攻撃のリスク
これらは独立した攻撃ですが、組み合わせて利用されることもあります。例えば、XSS脆弱性があるサイトでは、JavaScriptを使ってCSRFトークンを読み取ることが可能です。これにより、CSRF対策を突破されてしまう可能性があります。
したがって、Webセキュリティにおいては、CSRF対策だけでなく、XSS対策も同時に行うことが不可欠です。具体的には、ユーザー入力のエスケープ処理、Content Security Policy(CSP)の設定、HTTPOnly属性の付与など、多層的な防御が求められます。
開発者が知っておくべき実装上の注意点
CSRF対策を実装する際には、いくつかの重要なポイントがあります。これらを理解しておくことで、より確実な防御が可能になります。
GETリクエストで状態を変更しない
HTTP仕様では、GETリクエストは「データの取得」のみに使用し、「データの変更・削除」には使用すべきではないとされています。なぜなら、GETリクエストは画像の読み込みやリンクのクリックなど、様々な場面で自動的に発行されるため、CSRF攻撃の対象になりやすいからです。
状態を変更する処理には必ずPOST、PUT、DELETEなどのHTTPメソッドを使用し、これらに対してCSRF対策を施すことが基本です。
トークンの有効期限とローテーション
CSRFトークンは、セッションごとに生成するだけでなく、定期的にローテーション(再発行)することが推奨されます。また、使用済みのトークンを無効化する「ワンタイム」の仕組みを採用すると、さらにセキュリティが向上します。
ただし、ユーザーが複数のタブで同時に操作している場合などを考慮し、適切な実装を選択する必要があります。
フレームワークの機能を活用する
現代の主要なWebフレームワーク(Laravel、Ruby on Rails、Django、ASP.NET Coreなど)には、標準でCSRF対策機能が組み込まれています。これらは、トークンの生成・検証を自動的に行ってくれるため、開発者は機能を有効にするだけで基本的な対策が完了します。
重要なのは、これらの機能を無効にしないことです。「面倒だから」「動作しないから」という理由で対策を外してしまうと、アプリケーション全体が脆弱になります。動作しない場合は、設定を見直すか、フレームワークのドキュメントを確認しましょう。
【演習】CSRFの攻撃フローと3つの鉄壁対策 理解度チェック（全10問）
Webアプリケーションの利便性を逆手に取り、ユーザーになりすまして不正操作を行う「CSRF（クロスサイトリクエストフォージェリ）」。 本記事で解説した攻撃のメカニズムや、ワンタイムトークン、SameSite属性といった防御策について、正しく理解できていますか？
以下のクイズで、重要なポイントを効率よく復習しましょう。XSSとの違いや、開発者が気をつけるべき実装の注意点など、実務や試験に役立つ知識を全10問の選択式問題で確認できます。
まとめ
クロスサイトリクエストフォージェリ(CSRF)は、Webの根幹である「セッション管理」と「ドメイン間の通信」の隙間を突く、古くからある巧妙な攻撃手法です。
しかし、その仕組みさえ正しく理解していれば、対策は決して難しくありません。現代の主要なWebフレームワークには、標準でCSRF対策機能(トークンチェックなど)が備わっています。開発者はこれらの機能を無効にせず、正しく利用することが求められます。
CSRF対策の要点:
- 攻撃の原理:ログイン状態(Cookie)を悪用し、本人になりすましてリクエストを送信させる
- 最大の影響:金銭的被害、アカウント乗っ取り、社会的信用の毀損
- 根本対策:ワンタイムトークンの実装と検証
- 推奨設定:CookieのSameSite属性(LaxまたはStrict)の活用
- 重要な操作:パスワードの再入力を求める設計
- 基本原則:GETリクエストで状態を変更しない
セキュリティ対策は「知ること」から始まります。今回のCSRFの知識を武器に、ユーザーが安心して利用できる安全なWebサイト作りを目指してください。攻撃者は常に新しい手法を模索していますが、基本的な対策を確実に実装することで、多くの脅威から身を守ることができます。次回は、Webセキュリティにおいて避けては通れない認証の仕組みについて、さらに深掘りしていきます。