SameSite Cookie だけで CSRF を防げますか?

SameSite=Lax(最近のブラウザーの既定)は、トップレベルのナビゲーション(フォーム POST、リンクのクリック)に対する CSRF を防ぎますが、GET リクエストは許可します。SameSite=Strict はすべてのクロスサイト送信を防ぎますが、正当なクロスサイト利用(例:メールからあなたのサイトへのリンクをたどる)を壊します。多層防御のために SameSite=Lax + CSRF トークンを併用してください。

CSRF と XSS の違いは何ですか?

XSS は被害者のブラウザーで悪意あるコードを実行します(攻撃者がユーザーとしてデータを読み取り、操作を行います)。CSRF は被害者のブラウザーをだまして、認証済みサイトにリクエストを送らせます(攻撃者はレスポンスを読み取りません)。XSS はコードインジェクション、CSRF はリクエスト偽造です。XSS は CSRF 対策を回避できます(スクリプトがトークンを読めるため)。

CSRF(クロスサイトリクエストフォージェリ)攻撃を防ぐ

CSRF は認証済みユーザーを騙して意図しないリクエストを送信させます。anti-CSRF トークン、SameSite Cookie、ダブルサブミットのパターンを学びましょう。

1

CSRF は、ブラウザーが Cookie を自動送信する仕組みを悪用します。ユーザーがログイン済み(Cookie が存在)の状態で悪意あるサイトを訪れると、そのサイトはターゲットサイトにフォームを送信できます。Cookie は自動的に送られます。対策:(1) アンチ CSRF トークン(シンクロナイザーパターン)— フォームとセッションにランダムなトークンを入れ、送信時に検証。(2) SameSite Cookie — Cookie がクロスサイトで送信されない。(3) Origin/Referer ヘッダーの検証。(4) 状態を変更するリクエストにカスタムヘッダーを必須にする。
2

HMAC ジェネレーター →
アンチ CSRF トークンを生成します。トークンは、予測不可能(CSPRNG)、セッションごと(より高いセキュリティにはリクエストごと)、かつユーザーのセッションに紐付いているべきです。HMAC(session_id, random) が一般的なパターンです。決定論的(同じセッション → 同じトークン)ですが、シークレットなしでは偽造できません。
3

ハッシュ計算ツール →
ダブルサブミットパターンでは、ランダムなトークンを生成し、Cookie として設定し(JavaScript が読めるよう HttpOnly にしない)、毎リクエストのヘッダーに含めます。サーバーは Cookie とヘッダーが一致することを検証します。サーバー側の状態を必要としません。トークンのハッシュには SHA-256 を使ってください。

よくある質問

SameSite Cookie だけで CSRF を防げますか?: SameSite=Lax(最近のブラウザーの既定)は、トップレベルのナビゲーション(フォーム POST、リンクのクリック)に対する CSRF を防ぎますが、GET リクエストは許可します。SameSite=Strict はすべてのクロスサイト送信を防ぎますが、正当なクロスサイト利用(例:メールからあなたのサイトへのリンクをたどる)を壊します。多層防御のために SameSite=Lax + CSRF トークンを併用してください。
CSRF と XSS の違いは何ですか?: XSS は被害者のブラウザーで悪意あるコードを実行します(攻撃者がユーザーとしてデータを読み取り、操作を行います)。CSRF は被害者のブラウザーをだまして、認証済みサイトにリクエストを送らせます(攻撃者はレスポンスを読み取りません)。XSS はコードインジェクション、CSRF はリクエスト偽造です。XSS は CSRF 対策を回避できます(スクリプトがトークンを読めるため)。