CSRF（Cross-Site Request Forgery）は、ログイン中のユーザーに対して、本人が意図していない操作をWebサイト上で実行させる攻撃です。
たとえば、管理画面へログインしたまま別サイトを開いたとき、そのページから意図しない変更リクエストが送られると、ブラウザがログイン情報を自動で付けてしまい、正規ユーザーの操作として処理される可能性があります。
初心者は、「ログイン中の権限を悪用して、勝手な操作をさせる攻撃」と理解すると分かりやすいです。
30秒でわかる結論
30秒でわかる結論
- CSRFは、ログイン中ユーザーに意図しない操作をさせる攻撃
- 攻撃者がユーザーのパスワードを知らなくても成立する場合がある
- 被害例は、設定変更、メールアドレス変更、投稿削除など
- 対策の基本はCSRFトークン
- SameSite CookieやOrigin/Referer確認は防御を補強する
- 重要操作では再認証を加えると安全性が上がる
- WordPressではnonceを使うが、nonceは認証・権限確認の代わりではない
CSRFとは？
CSRFは「Cross-Site Request Forgery」の略で、日本語では「クロスサイトリクエストフォージェリ」と呼ばれます。
ユーザーがWebサービスへログインしている状態を利用し、別サイトなどからそのサービスへ不正なリクエストを送らせる攻撃です。
初心者向けに一言でいうと
本人が押していないボタンを、本人のログイン権限で押したことにされるような攻撃です。
CSRFが成立する仕組み
CSRFが成立しやすいのは、Webサービスが「ログインCookieが付いている＝本人の意図した操作」とだけ判断してしまう場合です。
パスワードを盗まなくても成立する
CSRFでは、攻撃者がユーザーのパスワードを直接知る必要がない場合があります。すでにログイン済みのセッションを悪用する点が特徴です。
CSRFで起こり得る被害
CSRFで悪用されるのは、ログイン中ユーザーが本来実行できる操作です。
| 操作例 | 影響 |
|---|---|
| メールアドレス変更 | アカウント乗っ取りにつながる可能性 |
| パスワード変更 | ログイン不能になる可能性 |
| 投稿削除 | コンテンツ消失 |
| 設定変更 | サイト挙動の変更 |
| 購入・送金操作 | 金銭的被害の可能性 |
ユーザーの権限がそのまま悪用される
一般ユーザーなら一般ユーザー権限、管理者なら管理者権限の範囲で被害が大きくなる可能性があります。
CSRFとXSSの違い
CSRFとXSSは混同されやすいですが、攻撃の仕組みが異なります。
| 項目 | CSRF | XSS |
|---|---|---|
| 主な悪用対象 | ログイン中ユーザーの権限 | Webページ内で実行されるスクリプト |
| 主な目的 | 意図しない操作をさせる | スクリプトを実行させる |
| 代表対策 | CSRFトークン、SameSite | 出力エスケープ、入力検証など |
XSSの仕組みと対策は「XSSとは？クロスサイトスクリプティングの仕組みと対策」で詳しく扱います。
CSRFとクリックジャッキングの違い
クリックジャッキングは、透明なiframeなどを重ねて、ユーザーに別のボタンを押させる攻撃です。
CSRFは、ユーザーが意図していないリクエスト自体を送らせる攻撃です。
違いの覚え方
CSRF＝勝手な操作を送る
クリックジャッキング＝見た目をだまして押させる
CSRFトークンとは？
CSRF対策の基本が、CSRFトークンです。
サーバー側で予測困難なトークンを生成し、フォーム送信時などに一緒に送信させます。サーバーは受け取ったトークンを検証し、正しい値でなければ処理を拒否します。
OWASPでは、CSRFトークンはユーザーセッションごと、またはリクエストごとに生成し、秘密・一意・予測困難であることを推奨しています。
SameSite Cookieとは？
Cookieには SameSite 属性を設定でき、他サイトを起点とするリクエストでCookieを送信する条件を制限できます。
| 値 | 考え方 |
|---|---|
| Strict | クロスサイト送信を強く制限 |
| Lax | 一部のトップレベル遷移などを許可 |
| None | クロスサイト送信を許可。Secureが必要 |
SameSiteだけに頼らない
OWASPは、一般的な構成ではSameSiteを防御の補助層として扱い、CSRFトークンなどと組み合わせることを推奨しています。
Origin・Referer確認も有効
重要なリクエストでは、HTTPの Origin や Referer を確認し、自サイトから送られたものか検証する方法があります。
これはCSRFトークンの代替として単独利用するより、防御を重ねる目的で使われます。
多層防御で考える
CSRFトークン、SameSite Cookie、Origin確認などを組み合わせると、1つの対策が破られた場合にも被害を防ぎやすくなります。
重要操作では再認証する
パスワード変更、支払い、送金、重要設定の変更などでは、操作直前にパスワード再入力や多要素認証を求める方法があります。
再認証を検討したい操作
- パスワード変更
- メールアドレス変更
- 管理者追加
- 支払い方法変更
- 送金・購入
- 重要なアカウント削除
OWASPも、セキュリティ上重要な操作では再認証やワンタイムトークンなどのユーザー操作ベース対策を強い防御として挙げています。
GETで重要な変更をしない
重要な状態変更を、単純なGETリクエストだけで実行できる設計は避けます。
避けたい考え方
URLを開くだけで「削除」「パスワード変更」「設定変更」が完了する
状態変更にはPOST・PUT・PATCH・DELETEなど適切なHTTPメソッドを使い、そのうえでCSRF対策を行います。
POSTに変えるだけでは不十分
POSTであっても、トークンなどの検証がなければCSRF対策として十分ではありません。
WordPressではnonceを使う
WordPressでは、フォームや管理画面操作のCSRF対策としてnonceが使われます。
WordPressのnonceは、通常の意味での「1回限りの値」とは少し異なり、一定時間有効なセキュリティトークンです。
WordPress nonceの役割
「このリクエストが正規画面から送られたものか」を確認するための追加情報として使われ、CSRF対策に役立ちます。
WordPress nonceだけで十分？
十分ではありません。
WordPress公式は、nonceを認証・認可・アクセス制御の代わりに使わないよう明記しています。
たとえば、管理者だけが実行できる処理なら、nonce確認に加えて、そのユーザーが本当に管理者権限を持っているかを確認する必要があります。
役割を分ける
nonce＝リクエストの正当性確認
権限チェック＝そのユーザーが操作できるか確認
WordPressサイト運営者ができる対策
初心者向けチェック
- WordPress本体を最新状態にする
- テーマ・プラグインを更新する
- 不要なプラグインを削除する
- 信頼できるテーマ・プラグインだけ使う
- 管理者権限を必要最小限にする
- 管理画面で不審な操作履歴がないか確認する
- 独自開発フォームではnonce・権限チェックを実装する
通常のWordPress利用者は、自分でCSRFトークンを一から実装するより、WordPress本体・テーマ・プラグインを最新状態に保つことが重要です。
プラグイン開発では何に注意する？
WordPressプラグインやテーマで、設定変更・データ更新・削除などを行う独自フォームを作る場合は、nonceを使ってリクエストを検証します。
さらに、ユーザーの権限を確認し、入力値の検証・サニタイズ、出力時のエスケープなども別途行います。
セキュリティ対策は1種類ではない
CSRF対策をしても、XSSやSQLインジェクションへの対策が自動的に完了するわけではありません。脆弱性ごとに必要な防御が異なります。
CSRF対策として不十分なもの
POSTにするだけ
POSTでも外部サイトから送信される可能性があるため、それだけでは不十分です。
JavaScriptで確認画面を出すだけ
見た目の確認だけでは、サーバー側のリクエスト検証にはなりません。
Cookieを使っているだけ
CSRFはCookieが自動送信される性質を悪用するため、Cookie認証だけでは防げません。
CAPTCHAだけ
OWASPは、CAPTCHAをCSRF専用の防御として推奨していません。Bot対策とCSRF対策は目的が異なります。
CSRF対策の優先順位
一般サイト運営者はどこまで理解すればよい？
仕組みを知り、WordPress・テーマ・プラグイン更新を優先すれば十分です。
管理画面を使う人の権限管理と更新運用を徹底します。
nonce・権限チェック・入力検証まで実装レベルで理解する必要があります。
CSRFトークン、Cookie属性、Origin検証などを組み合わせて設計します。
教科書判定
初心者は「ログイン済み権限を悪用される攻撃」と理解し、更新と権限管理を優先
一般的なWordPressサイト運営者が、CSRFトークンの実装を自分で行う必要は通常ありません。WordPress本体・テーマ・プラグインを更新し、不必要な管理者権限を与えないことが基本です。
独自フォームやプラグインを開発する場合は、nonceまたはCSRFトークンだけで終わらせず、権限確認・入力検証・SameSite Cookie・Origin確認などを組み合わせることが重要です。
よくある質問
Q．CSRFはパスワードを盗む攻撃ですか？
必ずしもそうではありません。CSRFは、すでにログインしているユーザーのセッションや権限を悪用して、本人が意図しない操作を実行させる攻撃です。
Q．POSTにすればCSRFは防げますか？
防げません。POSTでも不正リクエストを送信できるため、CSRFトークンなどの検証が必要です。
Q．SameSite Cookieだけで十分ですか？
一般的には、SameSiteだけへ依存せず、CSRFトークンやOrigin確認などと組み合わせるのが安全です。
Q．WordPressではCSRF対策が必要ですか？
WordPress本体ではnonceなどの仕組みが用意されています。通常利用では最新版を維持し、独自開発ではnonceと権限チェックを正しく実装することが重要です。
Q．WordPress nonceは1回だけ使える値ですか？
厳密には違います。WordPressのnonceは一定時間有効で、その間は同じ値が使われることがあります。CSRF対策には役立ちますが、認証や権限確認の代わりにはなりません。
まとめ
CSRFの要点
- CSRFはログイン中ユーザーに意図しない操作をさせる攻撃
- パスワードを直接盗まなくても成立する場合がある
- 対策の基本はCSRFトークン
- SameSite Cookieは防御を補強する
- Origin・Referer確認も有効
- 重要操作では再認証を検討する
- WordPressではnonceがCSRF対策に使われる
- nonceだけで認証・権限確認を代替してはいけない
- WordPress初心者は更新・権限管理・信頼できるプラグイン利用を優先する
「XSSとは？クロスサイトスクリプティングの仕組みと対策」「SQLインジェクションとは？仕組みと対策を解説」「セキュリティヘッダーとは？Webサイトで設定する意味」もあわせて確認してください。