CSRF tokenとは？偽造リクエストを阻止する仕組み

CSRF tokenとは、ユーザーセッションに紐づけられた予測不可能な値であり、状態を変更するリクエストが確かに自分自身のアプリケーションから発生したことを証明します。

CSRF tokenは、cross-site request forgeryに対して防御します。これは、悪意あるサイトがログイン済みユーザーのbrowserを騙して、別のサイトへ意図しないリクエストを行わせる攻撃です。browserはセッションcookieを自動的に送信するため、偽造されたリクエストは本物に見えます。CSRF tokenは、攻撃者が知り得ない秘密の値を要求することで、この攻撃を打ち破ります。

防ぐ攻撃

CSRF攻撃では、あるサイトにログイン済みの被害者が悪意あるページを訪れ、そのページがひそかにそのサイトへリクエストを送信します。browserがセッションcookieを付加するため、そのリクエストは正当に見えます。保護がなければ、そのアクションは被害者のアイデンティティの下で実行されてしまいます。

tokenがどう防御するか

サーバーは、自身のフォームにセッションごとの秘密のtokenを埋め込みます。
正当なリクエストはtokenを含み、サーバーはそれを検証します。
cross-siteの偽造はtokenを読み取れないため、そのリクエストは拒否されます。

なぜ機能するのか

攻撃者はbrowserにリクエストを送信させることはできますが、あなたのサイトからのレスポンスを読むことはできないため、tokenを知ることができません。状態を変更するアクションでその推測不可能なtokenを要求することで、偽造されたリクエストは検証に失敗します。

CSRF tokenとSameSite cookie

現代の防御は、cookieがcross-siteで送信されるタイミングを制限するSameSite cookie属性とCSRF tokenを組み合わせます。両者は多層的な保護を提供します。どちらか一方だけに頼ると、browserやシナリオによっては隙が残ることがあります。

CI/CDにおけるCSRF保護

Webアプリを構築するなら、状態を変更するエンドポイントでのCSRF保護は安全なコーディングの一部です。pipeline内のセキュリティテストやレビューは、変更が本番に到達する前に、フォームや安全でないメソッドが有効なtokenを要求することを確認すべきです。

防御の範囲

CSRF tokenは、cookie認証のbrowserベースのフローを保護します。bearer tokenで認証されるAPI（pipelineが使うパターン）は、自動送信されるcookieに依存しないため、一般にCSRFに対して脆弱ではありません。

重要なポイント

CSRF tokenは、リクエストが自分自身のアプリから来たことを証明する、推測不可能な値です。
cookie認証で状態を変更するアクションに対する cross-site request forgery をブロックします。
SameSite cookieと組み合わせましょう。bearer token方式のAPIは一般にCSRFの影響を受けにくいです。