CSRF（クロスサイトリクエストフォージェリ）

どう攻撃されるのか（仕組み）

ポイントは「被害者がすでに本物サイトにログイン済み」であることです。たとえば銀行サイト bank.example に session_id の Cookie でログインしているとします。この状態で、攻撃者の罠ページ evil.example を開いてしまうと――

<!-- evil.example に置かれた罠。被害者が開いた瞬間に勝手に送信される -->
<form action="https://bank.example/transfer" method="POST" id="f">
  <input type="hidden" name="to" value="attacker-account">
  <input type="hidden" name="amount" value="1000000">
</form>
<script>document.getElementById('f').submit();</script>

このフォームの送信先は bank.example です。ブラウザは「bank.example 宛のリクエストだから」と、保存済みの session_id Cookie を自動的に付けて送ります。サーバから見れば「正しいセッションを持った本人からの正規の送金依頼」と区別がつかず、処理してしまう。これが CSRF の核心です。

リクエストは <img src> や fetch でも仕掛けられ、被害者の画面には何も起きていないように見えるのが厄介な点です。攻撃の成立条件を整理します。

何が危険か

CSRF は情報を盗む攻撃ではなく、本人になりすまして「操作させる」攻撃です。だからレスポンスの中身（残高表示など）は攻撃者には見えません。それでも危険なのは、状態を変える操作（書き込み系）を本人の権限で実行できてしまうから。

• 送金・購入などの金銭被害
• メールアドレスやパスワードの変更によるアカウント乗っ取り（変更後に本人を締め出せる）
• 退会・データ削除などの取り返しのつかない操作
• 管理者が踏めば権限昇格や設定改ざんに直結

つまり「読めないから無害」ではありません。副作用のある操作を勝手に走らせられる点で、十分に致命的です。

XSS との違い

CSRF と XSS は名前が似ていて混同されがちですが、攻撃の方向がまったく逆です。ここを取り違えると対策もズレます。

対策：本命は CSRF トークン

最も確実なのは**CSRF トークン（同期トークン）**です。考え方はシンプルで、「攻撃者には推測も入手もできない秘密の値」をリクエストに要求し、それが無い／合わないものを弾きます。Cookie は自動で付けられても、この秘密の値までは攻撃者のページから埋め込めません。

// 1) フォーム表示時：セッションに紐づくランダムなトークンを発行し、画面に埋め込む
app.get('/transfer', (req, res) => {
  const token = issueCsrfToken(req.session); // 例: crypto.randomBytes(32) を保存
  res.render('transfer', { csrfToken: token }); // <input type="hidden" name="_csrf"> に出力
});

// 2) 送信時：届いたトークンとセッション側の値を突き合わせる
app.post('/transfer', (req, res) => {
  if (req.body._csrf !== req.session.csrfToken) {
    return res.status(403).send('Forbidden'); // 403 = 本人だが許可しない
  }
  doTransfer(req.body); // ここで初めて実行
});

罠ページからの送信には _csrf が無い（または推測値で外れる）ため、403 で止まります。

対策：SameSite Cookie で“自動送信”を絞る

そもそもの原因は「Cookie が別サイト発でも付く」ことでした。これをブラウザ側で制御するのが SameSite 属性です。

対策：Origin / Referer の確認

サーバ側で「このリクエストはどのサイトから来たか」を確かめる方法もあります。書き込み系（POST/PUT/DELETE）のリクエストに付く Origin（無ければ Referer）ヘッダを見て、自サイト以外なら拒否します。

// 状態を変える操作の前に、送信元オリジンを検証する
app.post('/transfer', (req, res) => {
  const origin = req.headers.origin || req.headers.referer;
  if (!origin || new URL(origin).host !== 'bank.example') {
    return res.status(403).send('Bad origin');
  }
  // …以降は CSRF トークン検証へ（重ねる）
});

Origin ヘッダは JS からは書き換えられないためなりすましが難しく、有効なチェックになります。ただし環境によっては Referer が送られない（プライバシー設定・プロキシ等）ため、これも単独ではなく、CSRF トークンと併用するのが堅実です。

やってはいけない“なんちゃって対策”

最後に、効きそうで効かない／不十分な対策を潰しておきます。

GET と状態変更（POST 等）の役割を分け、副作用のある操作を安全な経路に寄せる設計は、HTTP メソッドの安全性・冪等性の考え方とも地続きです。攻撃面の全体像は XSS や SQLインジェクション と合わせて押さえると、Web の脆弱性が立体的に見えてきます。