CSRF（クロスサイトリクエストフォージェリ）とは？XSSとの違いも含めて解説

CSRFとはどのような攻撃か

まずは攻撃の正体を押さえます。CSRFは、Webサイトが「ログイン中の本人からのリクエストだ」と信じ込む仕組みそのものを悪用する攻撃です。混同されやすいXSSとあわせて、何がどう違うのかを整理します。

クロスサイトリクエストフォージェリの仕組み

CSRFは「Cross-Site Request Forgery」の略で、日本語ではクロスサイトリクエストフォージェリと呼びます。「シーサーフ」と読まれることもあり、セッションライディングという別名も使われます。攻撃者は、利用者がログインしたままのWebサイトに向けて、本人が望んでいないリクエストを送信させます。

多くのWebサイトは、ログイン後の本人確認をCookieに保存したセッション情報で行っています。ブラウザーはそのサイト宛てのリクエストにCookieを自動で付けて送るため、出どころが攻撃者の用意したページであっても、サーバー側からは本人の操作と見分けが付きません。この「自動で送られるCookie」を悪用する点が、CSRFの本質です。

XSSとの違いは悪用される信頼の向きにある

混同されやすいXSS（クロスサイトスクリプティング）との違いは、悪意あるコードが動く場所と、悪用される信頼の向きにあります。XSSは脆弱なサイトの画面上で攻撃者のスクリプトを実行させる攻撃で、利用者がそのサイトを信頼していることを突きます。被害はCookieの盗み取りや画面の改ざんなど、情報の窃取にも及びます。

一方でCSRFは、攻撃者のスクリプトを標的サイト上で動かす必要がありません。まったく別のサイトに置かれたフォームやタグから、標的サイトへリクエストを送らせるだけで済みます。サーバーがそのリクエストを本人からのものだと信じてしまう点を突くため、被害は「意図しない処理の実行」という形で現れます。

CSRF攻撃が成立するまでの流れ

CSRFは、攻撃者が事前に標的サイトの処理を調べ、罠を用意し、利用者に踏ませるという順序で進みます。どの段階で何が起きているのかを知ると、どこを塞げばよいかが見えてきます。

攻撃者が標的サイトを調べて罠を用意する

攻撃はまず、標的サイトの更新処理を調べるところから始まります。会員情報の変更や退会、送金、投稿といった処理が、どのURLにどのようなパラメータで送られているかを確認し、それと同じリクエストを自動で送信する罠のページを作ります。

罠は、画像タグの読み込み1つで済む場合もあれば、隠したフォームをページの表示と同時に送信するスクリプトの場合もあります。状態を変更する処理をGETで受け付けているサイトは、リンクや画像を表示させるだけで攻撃が成立してしまいます。作られた罠は掲示板やSNSへの投稿、メールのリンクなどを通じて利用者に踏ませます。短縮URLや広告に紛れ込ませる手口もあります。

ログイン中の利用者が罠を踏んだときに起きること

利用者が標的サイトにログインしたままの状態で罠のページを開くと、ブラウザーは罠に仕込まれたリクエストを、利用者の操作を待たずに標的サイトへ送信します。このとき標的サイトのCookieが自動で付与されるため、サーバーにはログイン済みの本人からの正規のリクエストとして届き、そのまま処理が実行されます。

処理は利用者の目に触れないまま完了することが多く、画面には何も表示されない、あるいは無関係な画像が出るだけです。そのため被害に気付くのは、変更完了の通知メールを見たときや、後日あらためて設定を確認したときです。発覚が遅れやすく、原因の特定や影響範囲の調査にも時間がかかる点が、この攻撃の厄介なところです。

攻撃が成立しやすいサイトの条件

CSRFが成立するのは、(1)Cookieなどブラウザーが自動送信する情報だけで本人確認をしている、(2)リクエストの出どころを検証していない、(3)重要な処理のパラメータが推測できる、という条件がそろったときです。裏を返せば、どれか1つでも崩せば攻撃は成立しにくくなります。

例えば、更新処理のたびに推測できない値を求めれば(3)が崩れ、リクエストの送信元を確認すれば(2)が崩れます。会員情報の変更画面、退会処理、社内システムの承認画面など、ログイン後に「押すと何かが変わる」画面を洗い出しましょう。特に決済や権限変更に関わる画面から点検を始め、優先順位を付けて順に対応することが、対策の出発点だといえます。

CSRFで想定される被害

CSRFの被害は、実行された処理の内容によって大きく変わります。金銭やアカウントに直結する損害だけでなく、利用者自身が疑われてしまうという、運営側にとっても深刻な被害が生じる点を押さえておきましょう。

設定変更や金銭のやり取りに関わる被害

実害が大きいのは、アカウント情報や金銭に直結する処理を勝手に実行されるケースです。メールアドレスやパスワードを書き換えられればアカウントそのものを乗っ取られ、送金や商品の購入、ポイントの移転が実行されれば、そのまま金銭的な損害につながります。利用者から見れば身に覚えのない変更であり、問い合わせ対応の負担も重くなります。

管理者アカウントが狙われると被害はさらに広がります。管理画面から新しい管理ユーザーを追加されたり、公開設定やアクセス権限を変更されたりすれば、その後の侵入口を作られてしまいます。会員サイトやECサイト、社内の業務システムなど、ログイン後に更新処理を持つサイトは規模を問わず対象です。

利用者が加害者に見えてしまう被害

金銭以外の被害として見落とせないのが、利用者自身が加害者のように見えてしまう問題です。掲示板やSNSへの書き込みを勝手に実行されると、サイト側の記録には本人のアカウントから投稿された事実だけが残り、本人が否定しても潔白を示すのは簡単ではありません。

国内でも過去に、罠を踏んだ利用者のパソコンから掲示板へ犯行予告が書き込まれ、その持ち主が疑われる事態が起きたと報告されています。サイト側のログだけでは本人の操作かどうかを判断できないため、運営者にとっては「利用者を守れなかった」という信頼の問題にも発展します。書き込みや申し込みなど、第三者に影響が及ぶ処理ほど慎重な検証が求められます。

ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料を取り寄せて、さまざまな製品の機能や特徴を比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力（約60秒）でWAFの一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。

開発側で実装するCSRF対策

CSRF対策の本筋は、アプリケーション側でリクエストの正当性を確かめることです。ここでは中心となるトークンの照合に加え、CookieのSameSite属性やヘッダー検証という、組み合わせて使う手段を紹介します。

CSRFトークンでリクエストの出どころを確かめる

最も基本的な対策が、CSRFトークンの照合です。フォームを表示するときに、そのセッションに結び付けた推測困難な値を生成して画面のhidden項目に埋め込み、送信されたリクエストに含まれる値がサーバー側で保持している値と一致した場合だけ処理を実行します。

攻撃者は他人のセッションに対応するトークンの値を知ることができないため、外部サイトに置いた罠からは正しいリクエストを組み立てられません。主要なWebアプリケーションフレームワークはこの仕組みを標準で備えているので、提供されている機能を有効にするほうが安全です。あわせて、状態を変更する処理はGETではなくPOSTで受け付けるようにします。

CookieのSameSite属性で外部からの送信を制限する

CookieのSameSite属性は、別サイトを起点とするリクエストにそのCookieを付けるかどうかをブラウザーに指示する仕組みです。値はStrict、Lax、Noneの3種類で、Strictは外部サイトからの遷移では一切送らず、Laxはトップレベルの画面遷移かつGETなど安全なメソッドの場合に限って送信します。

Noneを指定する場合は、あわせてSecure属性を付ける必要があります。Chromeなど一部のブラウザーは属性が明示されていないCookieをLaxに近い扱いとするため、更新処理をPOSTで受けていれば一定の効果が期待できます。ただし既定の扱いはブラウザーごとに異なるため、トークン照合との併用が前提です。

OriginヘッダーやRefererヘッダーを検証する

リクエストに付くOriginヘッダーやRefererヘッダーを見て、自サイト以外から送られた更新処理を拒否する方法もあります。Originは送信元のスキームとホスト、ポートだけを伝えるため、ページのURL全体を含むRefererよりもプライバシー面の懸念が小さく、判定にも使いやすい情報です。

ただしRefererは利用者の設定やブラウザーの仕様で送られない場合があり、これだけに頼ると正規の利用者を弾いてしまいます。ヘッダーが無かった場合の扱いをあらかじめ決めたうえで、トークン照合を主、ヘッダー検証を従とする組み合わせが現実的です。JavaScriptから送る処理では、独自のヘッダーを必須にする方法も有効です。

WAFでCSRFを防ぐ場合の考え方

実装の修正には時間もコストもかかります。既存のシステムをすぐには直せない、あるいは対策の抜けが心配だという場合に、通信の入り口で守る手段がWAFです。担える役割と限界を正しく理解しておきましょう。

WAFが担える役割と限界

WAF（Webアプリケーションファイアウォール）は、Webアプリケーション宛ての通信内容を検査し、攻撃とみなした通信を遮断する仕組みです。CSRFに対しては、送信元を示すヘッダーが自サイト以外である更新リクエストを止めたり、製品によってはトークンの付与と検証を肩代わりしたりといった対応が可能です。

注意したいのは、WAFが万能ではないという点です。正規の利用者の操作と、攻撃者が仕組んだリクエストは形がよく似ており、通信の中身だけで完全に切り分けるのは簡単ではありません。WAFは、改修が間に合わない期間をしのぐ手段、実装対策の取りこぼしを補う層として位置づけるのが適切です。

導入形態の選び方と運用のポイント

WAFには、専用機器を設置するアプライアンス型、サーバーに導入するソフトウェア型、DNSの設定変更などで利用を始められるクラウド型があります。改修に時間がかかる既存システムを短期間で守りたい場合は、初期費用を抑えやすく導入までが早いクラウド型が候補になります。

導入後は運用が重要です。検知ルールを適用した直後は正常な通信を誤って遮断することがあるため、まず検知のみのモードで様子を見て、ログを見ながら除外設定を調整します。遮断の記録を定期的に振り返り、アプリケーション側の修正につなげれば、多層の防御が機能します。契約前には、対象にできるドメイン数や通信量の上限も確認しておきましょう。

「自社に合うWAFを診断してみたい」、「どんな観点で選べばいいかわからない」という方向けの診断ページもあります。
ITトレンドで過去資料を請求した方の、リアルなお悩みや要望から作成した簡単な質問に答えるだけで、最適な製品・サービスをご案内します。
無料で今すぐ利用できますので、下のリンクから診断を開始してください。

実装対策を補うWAF製品の選択肢

ここでは、Webアプリケーションを狙う通信を入り口で検査・遮断できる製品を取り上げます。改修に時間がかかる既存システムでも始めやすいクラウド型で、検知ルールの更新や運用の支援を受けられるものを選びました。

攻撃遮断くん(株式会社サイバーセキュリティクラウド)

株式会社サイバーセキュリティクラウド

資料請求リストに追加

製品詳細ページへ ＞

製品・サービスのPOINT

1. あらゆる規模のWebシステムへ導入できる最適なWAFを提供。
2. DDoS対策プランや定額制プランなど多数のサービスプランを提供。
3. 自社開発だからできる手厚いサポート体制。

Cloudbric WAF+

ペンタセキュリティ株式会社

資料請求リストに追加

製品詳細ページへ ＞

《Cloudbric WAF+》のPOINT

1. 特許取得のロジック＆AIエンジンを搭載、高い攻撃検知力
2. WAF/DDoS攻撃遮断/API保護/ボット対策/Malicious IP遮断
3. 24時間365日監視体制と専門家にお任せのマネージドサービス付帯

まとめ

CSRFは、ログイン中の利用者のブラウザーを踏み台にして、本人が意図しない処理を実行させる攻撃です。XSSと違いスクリプトを標的サイト上で動かす必要がなく、外部サイトから送らせるだけで成立します。防ぐ基本は、CSRFトークンの照合とCookieのSameSite属性の設定、送信元ヘッダーの検証です。すぐに改修できない場合は、WAFの併用も検討しましょう。