CSRF（Cross-Site Request Forgery、クロスサイトリクエストフォージェリ）は、Webサービスにログイン中の利用者を悪用し、本人の意図しない操作を勝手に実行させる攻撃である。攻撃者が用意した罠のページを踏むと、利用者のブラウザが正規サイトへ不正なリクエストを送ってしまい、退会・送金・設定変更といった操作が本人になりすまして行われる。利用者は気づかぬうちに加害の踏み台にされるため、Webアプリを開発するうえで必ず対策すべき代表的な脆弱性の一つとされている。たとえば、あるサービスにログインしたまま別のタブで悪意あるサイトを開いただけで、背後で勝手に退会処理や送金が実行されてしまう、といった事態が起こりうる。利用者自身は何も操作していないつもりでも、ブラウザが自動的に送る認証情報が悪用される点が、この攻撃の巧妙さであり恐ろしさだ。仕組みと対策を正しく理解することが、安全なサービス運営の前提となる。
CSRFの仕組み
CSRFは、ブラウザが正規サイトへ自動的に送る認証情報（Cookieなど）を悪用する。ログイン状態が保たれていることが攻撃成立の前提となる。
- ログイン状態の悪用
利用者が正規サイトにログインしていると、ブラウザはそのサイトへのリクエストに認証用のCookieを自動的に付ける。攻撃者はこの自動送信を利用し、本人のログイン状態を借りて不正な操作をさせる。
- 罠による不正リクエスト
攻撃者は、正規サイトへ操作を送るよう仕込んだ罠のページやリンクを用意する。利用者がそれを開くと、気づかぬうちにブラウザが正規サイトへリクエストを送信してしまう。
- 正規リクエストとの区別困難
送られてくるリクエストには正しい認証情報が付いているため、サーバー側からは本人の正当な操作と見分けがつきにくい。この見分けの難しさが攻撃を成立させる要因だ。
- 意図しない操作の実行
結果として、設定変更や送金、投稿、退会といった操作が本人の意思と無関係に実行される。利用者は自分が操作したと錯覚するか、まったく気づかないことも多い。
CSRFの危険性・影響
CSRFは、利用者本人になりすまして操作を行うため、被害が実害に直結しやすい。想定される影響を見ていく。
- 金銭的被害
送金や決済、商品の購入などが勝手に実行されると、直接的な金銭被害につながる。特に金融系のサービスでは深刻な損害を招きかねない。
- アカウントの乗っ取り
パスワードやメールアドレスの変更を勝手に行われると、アカウントを奪われる恐れがある。以降のログインを封じられ、被害が拡大する。
- 情報の改ざん・削除
登録情報の書き換えや投稿・データの削除など、本人の資産や情報が不正に操作される。取り返しのつかない損失につながることもある。
- 気づきにくさ
利用者は攻撃を受けたこと自体に気づきにくい。被害が表面化するまで時間がかかり、原因の特定も難しいため、対策の重要性が高い。
CSRFへの対策
CSRFは適切な対策で防げる脆弱性だ。Webアプリ側で複数の手立てを講じることが重要となる。
- CSRFトークン
正規の画面を経由したリクエストにのみ、推測困難な使い捨ての合言葉（トークン）を付与し、サーバーで照合する。罠のページはこのトークンを知り得ないため、不正なリクエストを弾ける。最も基本的で有効な対策だ。
- SameSite属性の設定
Cookieに適切な属性を設定し、別サイトからのリクエストには認証Cookieを送らないようにする。ブラウザの仕組みを使って、そもそも不正な自動送信を防げる。
- 重要操作での再確認
送金や退会など重大な操作の前に、パスワードの再入力や確認画面を挟む。本人の明確な意思を確認することで、なりすましによる実行を防げる。
- リクエスト元の確認
リクエストがどのサイトから送られてきたかを示す情報を確認し、想定外の送信元からの操作を拒否する。補助的な対策として組み合わせると有効だ。
CSRFが問題となる場面
CSRFは、ログイン状態で操作を行うあらゆるWebサービスで問題となりうる。注意すべき代表的な場面を紹介する。
- 会員制サービスの設定変更
ログイン中に行う各種設定の変更は、CSRFの標的になりやすい。メールアドレスやパスワードの変更が勝手に行われると、被害が深刻化する。
- 金融・決済サービス
送金や購入といった操作を持つサービスは、CSRFによる直接的な金銭被害の危険がある。厳重な対策が不可欠な領域だ。
- SNSや掲示板の投稿
本人になりすました投稿やメッセージ送信に悪用される恐れがある。不適切な内容を勝手に発信され、信用を損なう被害につながる。
- 管理画面の操作
権限を持つ管理者が狙われると、被害が一気に拡大する。ユーザー削除や設定変更など、影響の大きい操作を持つ管理機能は特に注意が必要だ。
- フォームによる各種申請
ログイン状態で送信する申し込みや変更のフォームも標的となる。意図しない申請が本人名義で行われる危険がある。
CSRFとXSSの違い
CSRFは、同じくWebの代表的な脆弱性であるXSS（クロスサイトスクリプティング）と混同されやすい。両者の違いを理解しておきたい。
- 攻撃の対象
CSRFは利用者の「ログイン状態」を悪用して操作を実行させる。XSSは不正なスクリプトを実行させて情報を盗んだり画面を改ざんしたりする。狙う仕組みが異なる。
- スクリプトの要否
CSRFは必ずしもスクリプトを必要とせず、リクエストを送らせるだけで成立しうる。XSSは対象サイト上でスクリプトを実行させることが前提だ。
- 被害の性質
CSRFは本人になりすました「操作の実行」が被害となる。XSSは情報の窃取やなりすまし表示など、より幅広い被害を及ぼしうる。
- 対策の方向性
CSRFはトークンやCookieの属性で防ぐ。XSSは入力値の無害化などで防ぐ。異なる脆弱性なので、それぞれに応じた対策を両方講じる必要がある。
CSRF対策のポイント
CSRFを確実に防ぐには、開発時から対策を組み込む姿勢が欠かせない。実務で意識したい要点を挙げる。
- フレームワークの機能を使う
多くのWebフレームワークはCSRF対策の仕組みを標準で備えている。自作せず、用意された機能を正しく有効にすることが、確実で効率的な対策となる。
- 状態を変える操作を守る
データの変更・削除・送金など、状態を変える操作には必ず対策を施す。単に情報を表示するだけの操作と区別し、守るべき箇所を漏らさないことが重要だ。
- 多層で防御する
トークン、Cookieの属性、重要操作の再確認などを組み合わせて多層的に守る。一つの対策に頼らず重ねることで、より堅牢に攻撃を防げる。
まとめ
CSRFは、ログイン中の利用者を悪用し、本人の意図しない操作を正規サイトへ実行させる攻撃だ。送金やアカウント乗っ取り、情報改ざんなど実害に直結し、利用者が気づきにくい点でも危険性が高い。しかし、CSRFトークンやCookieのSameSite属性、重要操作での再確認といった対策で確実に防げる脆弱性でもある。フレームワークの機能を活用し、状態を変える操作を漏れなく守り、多層で防御することで、CSRFのリスクを効果的に抑え、安全なWebサービスを実現できる。開発の初期段階から対策を組み込む意識を持つことが何より大切だ。