【入門編】 CSRF(クロスサイトリクエストフォージェリ)の攻撃シーケンスと対策 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

あなたの「留守」を狙う泥棒の手口：CSRF（クロスサイトリクエストフォージェリ）を理解しよう

こんにちは！日々の開発やセキュリティ対策、本当にお疲れ様です。

今日は、Webセキュリティの現場でよく耳にする「CSRF（シーエスアールエフ）」についてお話しします。名前は難しそうですが、仕組みを知れば「なるほど、そういうことか！」とスッキリ理解できるはずです。

専門用語を並べる前に、まずは身近な「家の防犯」に例えて、この攻撃がどんなものか見ていきましょう。

—

1. CSRFってなに？：勝手に「合鍵」を使われる悪夢

想像してみてください。あなたは自分の家（Webサービス）にログインして、リビングでくつろいでいる状態です。そこへ、見知らぬ泥棒がやってきて、あなたの家のインターホンを鳴らします。

本来なら、泥棒は鍵を持っていないので中には入れませんよね。しかし、CSRFという攻撃は、「あなたが鍵を開けたままにしている隙に、あなたの手を使って勝手にドアを開けさせる」という、極めて狡猾な手口です。

攻撃のメカニズム

1. 信頼関係の悪用: ブラウザは、あなたが一度ログインすると「この人は本人だ」という証明書（クッキーなど）を自動的に持ったままになります。
2. 誘導: 攻撃者は罠を仕掛けたサイトを用意し、何らかの理由であなたをそこに誘導します。
3. 強制実行: そのサイトにアクセスした瞬間、ブラウザは「あなたが操作したつもり」で、裏側で勝手にあなたの銀行口座から送金したり、パスワードを変更したりするリクエストを送信してしまいます。

つまり、泥棒はあなたの家の鍵を盗むのではなく、「あなた自身に開けさせる」のです。これがCSRFの恐ろしいところです。

—

2. 泥棒を防ぐための「二重の鍵」

この攻撃を防ぐには、どうすればいいでしょうか？鍵を頑丈にするだけでは足りません。「本当に本人が開けようとしているのか？」を確認する仕組みが必要です。

対策その1：Anti-CSRFトークン（合言葉）

これは、Webサイト側から渡される「使い捨ての秘密の合言葉」です。フォームを送信する際、この合言葉も一緒に送ることで、「あ、この操作はさっき私が発行した画面からのものだね」とサーバー側が判断できます。

// サーバー側で生成し、セッションに保存する
session_start();
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32)); // ランダムな秘密の文字列
}

// フォームには隠しフィールドとして埋め込む
echo '<input type="hidden" name="csrf_token" value="' . $_SESSION['csrf_token'] . '">';

送信されたリクエストを受け取る側では、このcsrf_tokenがセッション内の値と一致するかを必ずチェックしましょう。

—

対策その2：SameSite属性（ドアの防犯機能）

最近のブラウザには、クッキーに「このクッキーは、自分が発行されたサイト以外からアクセスされた時は使わせないよ」という制限をかける機能があります。これが SameSite 属性です。

サーバーからクッキーを発行する際、以下のように設定するだけで劇的に安全性が高まります。

# HTTPレスポンスヘッダーの例
Set-Cookie: session_id=abc12345; SameSite=Lax; Secure

SameSite=Lax: 基本的に同じサイトからのリクエストのみでクッキーを送信します。（リンクをクリックして移動した時などは例外的に許可される、バランスの良い設定です）
SameSite=Strict: より厳格に、完全に同じサイトからしかクッキーを送りません。

—

3. 実務で明日からできること

新人のIT担当者や開発者の方が、まず最初に取り組むべきステップは以下の通りです。

1. すべての状態変更を伴うリクエストにトークンを仕込む:
GETメソッド（情報の表示）ではなく、POSTやPUT、DELETEなど、データを書き換える処理には必ずトークン認証を必須にしましょう。

2. クッキーの設定を見直す:
サーバーのセッション管理設定を確認し、SameSite=Lax が適用されているかチェックしてください。これだけで、CSRFの成功率は格段に下がります。

3. 「怪しいリンクは踏まない」という基本:
これは自分たちだけでなく、ユーザーへの啓発も大切です。「パスワードを変更してください」といったメール内のリンクを不用意にクリックしないよう、ユーザーガイドに一言添えるだけでも大きな防犯になります。

—

まとめ：セキュリティは「疑うこと」から始まる

CSRFは、「ブラウザが自動的にやってくれる便利さ」を逆手に取った攻撃です。だからこそ、私たちは「ブラウザが勝手に送る情報を、サーバー側で鵜呑みにしない」という姿勢を持つことが大切です。

「本当に本人かな？」「本当に意図した操作かな？」という疑いの目を持ってコードを書くこと。それが、あなたの作ったサービスを守る最強の武器になります。

一歩ずつ、着実に学んでいきましょう！もし分からないことがあれば、いつでもまた聞きに来てくださいね。あなたの開発ライフが、より安全で素晴らしいものになることを応援しています！