Web開発者が知っておくべき CSRF攻撃の仕組みと対策のすべて

1. 導入：なぜ今、CSRF対策が必要なのか？

Webアプリケーション開発者の皆さん、あなたのサイトのセキュリティ対策は万全ですか？

特に、ユーザーの認証情報を悪用し、意図しない操作を実行させる「CSRF（クロスサイトリクエストフォージェリ）攻撃」は、基本的なセキュリティ対策として最優先で理解し、対策を講じる必要があります。

この記事では、CSRF攻撃が成立する原理を深く掘り下げ、Web開発者が現場で**確実かつモダンに実装できる対策（CSRFトークン、SameSite Cookie）**を網羅的に解説します。この記事を読むことで、あなたのアプリケーションを不正なリクエストから守るスキルが身につきます。

**CSRF（Cross-Site Request Forgery）**とは、「クロスサイトリクエスト偽造」と訳され、攻撃者が用意した罠によって、認証済みのユーザーのブラウザから、ユーザーが意図しないリクエスト（データ更新、削除、送金など）をターゲットサイトへ送信させる攻撃です。

攻撃が成立するには、以下の3つの条件が揃っていることが必要です。

セッションが有効であること: ユーザーがターゲットサイト（例：銀行）にログインした状態であること。
リクエストの推測が可能であること: 攻撃者が、ターゲットサイトが受け付けるリクエストのURLやパラメーター（例：送金先、金額）を事前に知っている、または推測できること。
ブラウザがCookieを自動送信すること: ターゲットサイトへのリクエスト時に、ブラウザがセッションIDを含むCookieを自動で添付すること。

CSRF攻撃は、多くの場合、以下の流れで実行されます。

認証: ユーザーが正規のサービス（例：オンラインバンキング）にログインし、セッションCookieがブラウザに保存される。
誘導: ユーザーが悪意のあるサイト（攻撃者が用意した罠サイト）を訪問する。
偽造リクエストの発動: 罠サイトに埋め込まれた非表示のフォームや画像タグなどにより、ユーザーの意思に関係なくターゲットサイトへのリクエストがブラウザから自動的に送信される。
誤認: ブラウザはセッションCookieを自動で添付するため、ターゲットサイトのサーバーは、このリクエストを正規のユーザーからの操作だと誤認し、処理を実行してしまう。

攻撃者は、この仕組みを利用し、被害者のアカウントを使った「パスワード変更」や「送金処理」などを実行させます。

CSRFの対策は、攻撃成立の条件である「セッションCookieの自動送信」を防ぐことに焦点を当てます。以下の2つのアプローチが現在のWeb開発において必須とされています。

CSRFトークンは、フォームが正規のサイトから生成されたものかを検証するための秘密の鍵を使用する、最も確実な対策です。

リクエストごとに予測不可能なランダムな文字列（トークン）を生成し、サーバー側（セッション）とクライアント側（フォームの隠しフィールド）の両方で保持します。リクエスト送信時に両者の値を照合し、一致しなければ不正なリクエストとして破棄します。

ほとんどのモダンなWebフレームワーク（Ruby on Rails, Django, Laravelなど）には、このトークンを自動で処理する機能が標準搭載されています。

SameSite Cookie属性は、ブラウザ側でCookieの送信ルールを制限する、近年主流になりつつあるモダンな対策です。

Cookieに SameSite 属性を設定することで、クロスサイト（外部サイト）からのリクエストに対して、ブラウザがセッションCookieを自動送信するのを防ぎます。

属性値	説明	推奨度
Strict	最も厳格。クロスサイトからのリクエストではCookieを一切送信しない。	セキュリティ最優先の場合
Lax	推奨。GETリクエスト（リンク遷移など）の場合のみCookieを送信し、POSTなどデータ変更を伴うリクエストでは送信しない。	利便性とセキュリティのバランスが良い
None	制限なし。従来の動作と同じ。httpsとSecure属性が必須。	例外的な場合にのみ使用