【入門編】CSRF(クロスサイトリクエストフォージェリ)の攻撃メカニズムとSameSite属性の完全理解 – アプリケーションセキュリティ & 安全な開発防御ガイド

鍵はかかっているのに泥棒が入る？「CSRF」と「SameSite属性」の正体を暴く

こんにちは。セキュリティの現場で日々、巧妙化する攻撃と戦っている私です。

今日は、初心者エンジニアが必ず一度は躓く「CSRF（クロスサイトリクエストフォージェリ）」という攻撃についてお話しします。名前は難しそうですが、仕組みを知れば「なるほど、そういうことか！」と納得できるはずです。

専門書のような堅苦しい話は置いておいて、身の回りの「家の防犯」に例えながら、一歩ずつ紐解いていきましょう。

—

1. CSRF（クロスサイトリクエストフォージェリ）とは？

一言で言うと、「あなたになりすまして、勝手にドアを開けさせる攻撃」です。

泥棒のテクニックを想像してみてください

あなたが自宅の玄関（Webサイト）にログインして鍵を開けっ放しにしているとします。そこに泥棒（悪意のあるサイト）がやってきて、あなたの手を勝手に操り、「冷蔵庫の中身を全部出せ」という命令ボタンをポチッと押させる……これがCSRFです。

Webブラウザは、「あなたがログインしているサイト」からの要求であれば、たとえそれが裏で勝手に行われたものだとしても、「本人からの依頼だ！」と信じて忠実に実行してしまいます。

攻撃のメカニズム:

1. あなたが銀行サイトにログインする（認証状態になる）。
2. 攻撃者が仕掛けた悪意あるサイトを開く（知らずに踏んでしまう）。
3. そのサイトが、あなたのブラウザ経由で銀行サイトに「送金しろ！」という命令を勝手に送る。
4. ブラウザは銀行のログインクッキーを添えて送るため、銀行側は「本人からの依頼だ」と勘違いして送金を実行してしまう。

—

2. 救世主「SameSite属性」の登場

この攻撃を防ぐために、ブラウザ側で導入された強力な武器がCookieの「SameSite属性」です。これは「このクッキーは、発行元であるWebサイト以外からのリクエストには使い回しちゃダメだよ」というお約束（制限）のことです。

3つのモードを理解しよう

Cookieを設定する際、以下のいずれかを指定します。

Strict（厳格）：

一番安全です。どのリンクから飛んできても、他のサイト経由のリクエストには一切Cookieを使いません。ただし、外部サイトのリンクから自分のサイトに戻ってきたときも「ログインしていない状態」に見えてしまうため、利便性と引き換えにするイメージです。

Lax（緩やか）：

今のブラウザの標準です。ユーザーが「リンクをクリックした時」だけはCookieを送ることを許可します。でも、勝手に実行される「画像読み込み」や「フォーム送信」にはCookieを使いません。迷ったらまずはこれです。

None：

制限なしです。昔はこれが標準でしたが、今は「Secure属性（https通信のみ）」とセットでないとブラウザに拒否されます。どうしてもクロスドメインでCookieが必要な特殊なケース以外は使わないのが吉です。

—

3. 実践！安全なCookie設定コード

Webサーバーの設定や、アプリケーションの言語によって書き方は少し違いますが、基本は同じです。以下はNode.js（Express）での設定例です。

// セッションやクッキーの設定例
res.cookie(‘session_id’, ‘あなたの秘密のトークン’, {
httpOnly: true, // JavaScriptから盗まれないようにする（XSS対策）
secure: true, // https通信のみで送信する
sameSite: ‘lax’ // CSRFを防ぐための要！勝手なリクエストにはCookieを載せない
});

—

4. 防御の限界と、「これだけは知っておいてほしい」注意点

「SameSite属性を設定したからもう完璧！」……と言いたいところですが、セキュリティの世界に「絶対」はありません。

1. 古いブラウザの落とし穴： 非常に古いブラウザを使っているユーザーには、SameSite属性が効きません。
2. Laxの限界： Laxは「リンククリック」というユーザーの意図的な動作を許可してしまうため、巧妙に作られた罠には弱い側面があります。

本当の「安心」を手に入れるために

SameSite属性はあくまで「最後の砦」です。本質的な対策としては、以下の2つを必ず併用してください。

CSRFトークンを導入する：

フォームを送信する際、毎回サーバー側で生成した「一度限りの秘密のパスワード（トークン）」を一緒に送ってもらいます。攻撃者はこのトークンを知らないので、勝手にリクエストを作ることができません。

重要な処理には再認証を：

送金やパスワード変更など、重要な操作の前には「もう一度パスワードを入力してください」と求める仕組みを入れましょう。これが物理的な鍵を二重にする最強の防衛策です。

—

最後に：セキュリティは「泥臭い積み重ね」です

セキュリティ対策に派手な魔法はありません。
「Cookieを適当に設定しない」「トークンで本人確認を徹底する」「重要な操作には再確認を挟む」。こういった泥臭い基本の積み重ねこそが、あなたのサイトとユーザーを守ります。

まずは今日のプロジェクトのCookie設定を眺めてみてください。SameSiteは指定されていますか？もし空っぽなら、それがあなたの最初の改善ポイントです。

一歩ずつ、一緒に安全な開発を極めていきましょう！