CSRF（クロスサイトリクエストフォージェリ）とは？XSSとの違いや攻撃への対策を紹介

CSRF攻撃の仕組み

CSRF攻撃の仕組みは、ユーザーがログインしているセッションを悪用することにあります。この攻撃は、基本的に以下のような流れで実行されます。

この結果、パスワードの変更や金銭の送金など、企業や個人にとってリスクの大きい処理が意図せずに実行されます。

XSSとの違い

CSRFとよく比較される別の攻撃手法に、XSS（クロスサイトスクリプティング）があります。XSS攻撃は、悪意のあるスクリプトをWebサイトやWebアプリケーションに埋め込むことで、ユーザーのデータを盗んだり、不正な操作を行わせたりするサイバー攻撃です。

CSRF攻撃はWebアプリケーションのセッション管理を悪用するのに対し、XSS攻撃は出力処理の問題を悪用します。XSS攻撃では攻撃者が不正なスクリプトを埋め込み、第三者のユーザーがそれを実行することで被害に繋がります。

このようにCSRF攻撃とXSS攻撃では仕組みや手段が異なりますが、どちらもWebサイトやWebアプリケーションにとって深刻な脅威となるため、状況に適した事前対策が必要です。

なお、CSRFはフィッシング攻撃と混同されることもあります。フィッシングは偽サイトにユーザー自身が情報を入力してしまうことで被害が発生する攻撃です。一方、CSRFはユーザーが正規サイトにログインしている状態を悪用し、本人が気づかないうちに意図しない操作を実行させる点が大きく異なります。

【関連記事】XSS（クロスサイトスクリプティング）とは？攻撃手法と5つの対策を紹介

登録情報やパスワードが勝手に変更される

CSRF攻撃により、アカウントの登録情報やパスワードが無断で変更されることがあります。それに伴い、攻撃者によってアカウントが乗っ取られ、個人情報の漏洩や不正アクセスの危険にさらされる可能性があります。

口座から不正に送金される

攻撃者によって銀行や決済サイトのセッションが悪用され、ユーザーの口座から不正に送金が行われるケースもあります。この種の攻撃では、金銭的な被害が直接的に発生し、自分の意思に反して高額な被害が生じることとなります。

企業の機密情報が外部に漏洩する

企業の内部システムに対するCSRF攻撃により、機密情報が外部に漏洩するリスクも存在します。具体的には、重要なビジネス情報や顧客データ、アクセス情報などが含まれます。

このような攻撃は、企業の信頼性損失や法的責任、さらにはビジネスの存続にも関わる深刻な問題を引き起こす可能性があります。

悪意のある投稿や犯罪予告をされる

SNSなどのアカウントが乗っ取られ、悪意のある投稿や犯罪予告に利用されるリスクも考えられます。悪意のある投稿により、個人への誹謗中傷や企業への名誉毀損が発生し、結果としてユーザーが加害者として責任を問われることもあります。

はまちちゃん事件

2005年4月、SNSの「mixi」をターゲットとしたCSRF攻撃により、特定のURLをクリックすると勝手に「ぼくはまちちゃん！」というタイトルで⽇記がアップされてしまう現象が発生しました。日記が勝手に投稿されるだけで、幸いにも大きな実害はありませんでした。

サービスを提供しているイー・マーキュリーは、この件について「ハッキングでもなく、サーバ攻撃やウイルスでもない。ID盗難などの被害は発生していない」という回答をしており、「それ以上はコメントできない」とも述べています。実際、「はまちちゃん事件」ではIDなどの流出はありませんでしたが、CSRF攻撃の影響力を世間に知らしめるきっかけとなりました。

パソコン遠隔操作事件

2012年6⽉から9⽉にかけて、攻撃者が他人のパソコンを遠隔操作し、殺害や爆破予告など13件もの犯罪予告を行いました。これを受け、著名人を含む複数の容疑者が逮捕されました。

しかし、警察が逮捕された人物が使用していたパソコンを再度調べたところ、マルウェアが仕込まれていたことがわかり、パソコンが遠隔操作されて書き込みを行っていたことが判明。結果として、これらの逮捕は全て誤認逮捕だったのです。

その後、予告のあったサイトの脆弱性を狙ったCSRF攻撃だと判明し、長期にわたる捜査の結果、2013年2月に真犯人が逮捕されました。

Refererヘッダでリンク元を検証する

Refererヘッダを使用することで、リクエストが正当なものかどうかを確認できます。リクエストが信頼できるソースから送信されているかをチェックすることで、不正なアクセスを効果的に防ぐことが可能です。

サーバー側でRefererヘッダを検証することにより、悪意あるリクエストを事前に識別し、迅速に対処できるようになります。不正なリンク元からのリクエストを特定してブロックすることで、CSRF攻撃のリスク軽減に繋がるのです。

しかし、ブラウザの設定などでRefererの送信を無効にしている場合、サービスを利用できなくなる可能性があります。また、チェック漏れが発生するリスクもあるため、他の対策と併用して行うことが推奨されます。

ワンタイムトークンを使用する

ワンタイムトークンの使用もCSRF攻撃に対して有効です。この方法では、各フォーム送信ごとに一意のトークンが生成され、重要な処理が実行される際にトークンの確認が行われます。

トークンが一致せず、確認が完了しなかった場合、第三者からのリクエストは拒否されます。これにより、不正な操作が実行されることを事前に防止します。

ワンタイムトークンはセッションごとに生成されるため、攻撃者がトークンを予測することは非常に困難です。ワンタイムトークンの使用は突破されにくいCSRF対策だと言えます。

また、Django（Python）、Laravel（PHP）、Ruby on Rails、Spring Security（Java）など、主要なWebアプリケーションフレームワークにはCSRFトークンがデフォルトで組み込まれています。これらのフレームワークを利用している場合は、設定を正しく有効にするだけで基本的な対策が可能です。

参考：OWASP「Cross-Site Request Forgery Prevention Cheat Sheet」

SameSite属性をCookieに設定する

CookieにSameSite属性を設定することで、クロスサイト（異なるサイト間）でのCookie送信を制限し、CSRF攻撃を緩和できます。SameSite属性には3つの値があり、それぞれ異なるレベルでCookieの送信を制御します。

現在、Google ChromeやFirefoxなど主要ブラウザはSameSite属性のデフォルトをLaxとして扱うため、未設定でも一定の保護が働きます。ただし、古いブラウザでは対応していないケースや、外部サービス連携でSameSite=Noneに設定しているケースもあるため、SameSite属性だけに頼らず、CSRFトークンなど他の対策と組み合わせることが重要です。

参考：MDN Web Docs「Set-Cookie - SameSite」

重要な処理の前に再認証を求める

パスワード変更や送金といった重要な処理を実行する直前に、パスワードの再入力やCAPTCHAの入力をユーザーに求める方法も有効です。CSRF攻撃では攻撃者がユーザーに代わってリクエストを送信しますが、再認証を設けることで、ユーザー本人の操作でなければ処理が完了しない仕組みを作れます。

この対策はIPA「安全なウェブサイトの作り方」でも推奨されており、画面設計の変更を伴いますが、CSRFトークンの実装が難しい場合の代替策として有効です。トークンとの併用により多層的な防御を実現できるため、特に金銭や個人情報に関わる処理では積極的に導入を検討しましょう。

参考：IPA「安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）」

脆弱性診断を定期的に実施する

自社のWebサイトやWebアプリケーションにCSRFの脆弱性が残っていないかを定期的にチェックすることも重要な対策です。開発時にCSRFトークンを実装していても、後から追加した機能やプラグインに対策漏れがあるケースは珍しくありません。

脆弱性診断では、CSRF以外にもXSSやSQLインジェクションなど複数の脆弱性をまとめて検出できるため、Webサイト全体のセキュリティ向上に効果的です。自社での対応が難しい場合は、外部の専門サービス（Webアプリケーション診断など）を活用することで、より精度の高い検査が可能になります。

参考：IPA「安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）」

Webサービスの利用後はこまめにログアウトする

CSRF攻撃は、ユーザーがWebサービスにログインした状態でなければ基本的に成立しません。そのため、利用が終わったらこまめにログアウトすることが最も手軽で効果的な自衛策です。

特にネットバンキングや決済サービスなど、金銭的な被害に直結するサービスでは、利用後すぐにログアウトする習慣をつけましょう。「ログイン状態を保持する」設定はブラウザを閉じてもセッションが残り続けるため、CSRF攻撃のリスクを高めることになります。

参考：IPA「安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）」

不審なURLやメールのリンクを安易にクリックしない

CSRF攻撃は、攻撃者が用意した罠サイトにユーザーを誘導することで始まります。そのため、不審なURLやメール・SNSで送られてくるリンクを安易にクリックしないことが基本的な防御策です。

たとえば、身に覚えのない差出人からのメールに含まれるリンクや、SNS上で拡散されている短縮URLなどには注意が必要です。リンク先のURLを事前に確認し、正規のドメインかどうかをチェックする習慣をつけることで、罠サイトへの誘導を防ぎやすくなります。

参考：IPA「不正なメールに注意」

身に覚えのない操作履歴があればサービス元に報告する

自分では行っていない送金・投稿・設定変更などに気づいた場合は、CSRF攻撃を受けた可能性があります。まずはパスワードを速やかに変更し、サービス提供元に状況を報告しましょう。

被害の早期発見・早期報告が、被害の拡大を防ぐカギです。放置すると不正操作が繰り返されたり、攻撃者にアカウントを完全に乗っ取られたりするリスクがあります。不審な操作履歴を見つけたら、まず落ち着いてパスワード変更→サービス提供元への連絡の順で対応してください。

参考：IPA「情報セキュリティ安心相談窓口」