CSRF トークン.

CSRF トークンは、クロスサイトリクエストフォージェリに対する定番の防御策です。この攻撃は OWASP Top 10 2013 で A05 にランク付けされ、後の版では「アクセス制御の不備(Broken Access Control)」に統合されました。サーバーは暗号論的にランダムな値を生成し、それをユーザーのセッションに紐づけて、HTML フォームに埋め込むか、カスタムリクエストヘッダー用に公開します。同一オリジンポリシーによって攻撃者のページがトークンを読み取れないため、偽造されたクロスサイト要求は正しい値を渡せず、拒否されます。

主に 3 つのパターンがあります。**同期トークン方式(synchronizer token pattern)**は期待値をサーバー側に保存するもので、最も堅牢ですがステートフルです。ダブルサブミットクッキーはクッキーと、対応するフォームフィールドまたはヘッダーを比較するもので、サーバー側の状態は不要ですが、攻撃者がサブドメイン経由でクッキーを書き込める場合には脆弱です。署名付き(HMAC)ダブルサブミットはトークンをセッションに紐づけることでこの隙を塞ぎます。トークンはセッションごと(機微な操作ではリクエストごと)に発行し、十分に長く、一定時間比較(constant time)で照合しなければなりません。

多層防御が重要です。Chrome 80(2020 年 2 月)以降、明示されていないクッキーは既定で SameSite=Lax となり、ほとんどのクロスサイト POST を遮断します。しかし Lax でもトップレベルの GET ナビゲーションは許可され、すべてのブラウザがこれを強制するわけではないため、トークンは依然として必要です。トークンは Origin/Referer 検証や厳格な CORS と組み合わせましょう。JavaScript からのみ呼び出される bearer トークン API は、暗黙のクッキーを使わないため一般に CSRF トークンを必要としませんが、それでも再生(リプレイ)攻撃対策と認可制御は必要です。

flowchart TD
  A[ユーザーがフォームを読み込む] --> B[サーバーがセッション紐づけ CSRF トークンを発行]
  B --> C[隠しフィールドまたはカスタムヘッダーにトークン]
  C --> D[ユーザーが状態を変える要求を送信]
  D --> E{トークンはセッション値と一致するか}
  E -- はい --> F[要求を処理]
  E -- いいえ または欠落 --> G[403 で拒否 偽造要求]
  H[攻撃者のクロスサイトフォーム] -. トークンを読めない .-> G