CSRF は Cross-Site Request Forgery の略で、ログイン済みユーザーのブラウザに、本人が意図していないリクエストを送らせる攻撃です。
サーバーから見るとログイン済みユーザーの操作に見えるため、設定変更、投稿、退会、メールアドレス変更、送金などの重要操作で問題になります。
まず押さえたいポイント
- ログイン済み状態を悪用する攻撃
- ユーザー本人が画面を操作したように見えることがある
- 基本対策はCSRFトークン
- SameSite Cookieや重要操作の再認証も有効
- GETリクエストで状態変更をしないことが大切
どんな場面で出てくる？
ログイン後の設定変更、プロフィール更新、管理画面の削除操作、決済や送金、メールアドレス変更などで出てきます。
攻撃者は、別サイトやメール内のリンク、画像タグ、フォームなどを使って、被害者のブラウザから対象サービスへリクエストを送らせようとします。
CSRFは、XSSのようにスクリプトを直接実行する攻撃とは少し違います。
ポイントは、ブラウザが対象サイトのCookieを自動で送る性質を利用し、ログイン済みセッションに乗って操作を送ることです。
よくある誤解
「ログインが必要な画面だから安全」と考えるのは危険です。
CSRFはログイン済みであることを利用するため、ログインしているからこそ問題になります。
また、「POSTなら安全」とも言い切れません。
POSTでもCSRFトークンがなければ、条件によっては外部サイトから送られる可能性があります。重要なのは、リクエストが本当に正規画面から送られたものかを検証することです。
実務で見るポイント
Laravelなどのフレームワークでは、通常のWebフォームにCSRFトークンを入れる仕組みが用意されています。
ただし、API、SPA、外部サービスからのWebhook、モバイルアプリ連携などでは、どの通信にCSRF対策が必要で、どれは別の認証方式で守るのかを整理する必要があります。
初心者はまず、「状態を変える操作にはCSRFトークン」「GETで削除や更新をしない」「重要操作は再認証や確認画面を入れる」と覚えると実務で判断しやすくなります。
CSRFは地味ですが、ログイン済みユーザーの権限を借りる攻撃なので、管理画面では特に軽視しない方がよいです。