こんにちは。セキュリティの世界へようこそ。
現場で泥にまみれながらインシデント対応をしていると、ふと思うことがあります。「なぜ、家には立派な鍵をかけるのに、自分が作ったWebサイトの鍵はこんなに隙だらけなんだろう」と。
今回は、Web開発の現場で意外と見落とされがちな「セッション固定化攻撃（Session Fixation）」について、セキュリティのプロの視点から、じっくり紐解いていきましょう。
—
1. 「セッション固定化攻撃」って、結局何なの？
まずはイメージしてみてください。あなたは高級ホテルのフロント係です。
ある泥棒が、宿泊客になりすまして部屋に忍び込もうと企んでいます。
1. 罠を仕掛ける： 泥棒は、先にホテルに来て、フロントから「まだ誰も使っていないはずの合鍵（セッションID）」を盗み出します。
2. 獲物を待つ： 泥棒は、その合鍵をターゲットのAさんに「これ、割引クーポンがついてる特別な鍵ですよ」と渡します。
3. 罠にはまる： Aさんは何も知らずにその鍵を使ってホテルのサイトにログインします。
4. 成りすまし： Aさんがログインに成功した瞬間、その鍵は「Aさんとして通行許可された鍵」に昇格します。しかし、その鍵をすでに泥棒も持っていますよね？
結果、泥棒はAさんの名前で部屋に堂々と入ることができる。これが「セッション固定化攻撃」の仕組みです。「最初から決まった鍵（セッションID）を相手に使わせる」という点が、この攻撃の狡猾なところです。
—
2. 対策の基本：ログインしたら「鍵を新調する」
この攻撃を防ぐための唯一にして最強の鉄則は、「ログインの前後でセッションIDを強制的に捨てて、新しいものに入れ替える」ことです。
先ほどのホテルの例で言えば、Aさんがフロントで「ログインしました！」と言った瞬間に、フロント係が「では、古い鍵は無効にします。こちらが新しい正真正銘の鍵です」と、新しい鍵を渡すイメージです。これなら、泥棒が持っていた古い鍵はただのプラスチック片になってしまいますよね。
実装のヒント（PHPの例）
多くのフレームワークでは自動的にやってくれますが、生のPHPなどで書く場合はこうです。
// ログイン処理の直後
session_start();
// 既存のセッションを破棄して、新しいIDを生成する
// これが最強の防衛策です！
session_regenerate_id(true);
// これ以降、認証済みであることを示すフラグを立てます
$_SESSION[‘user_id’] = $authenticated_user_id;
たったこれだけのコードですが、これが「安全な開発」の第一歩です。
—
3. Cookie属性で「泥棒の侵入経路」を塞ぐ
セッションIDを守るためには、そのIDを運ぶ「Cookie」のガードも固める必要があります。以下の3つの属性は、いわば「鍵の持ち出し禁止ルール」です。
- `HttpOnly`属性：
「JavaScriptからは読み取り禁止！」というルールです。もしサイトに脆弱性があって、悪意あるスクリプトが埋め込まれても、Cookieが盗まれるのを防ぎます。
- `Secure`属性：
「暗号化された通信（HTTPS）でしか送っちゃダメ！」というルールです。Wi-Fiの盗聴などから守ります。
- `SameSite`属性：
「他のサイトからのリクエストには、このCookieを付けないで！」というルールです。最近のWeb開発では `Lax` または `Strict` に設定するのが常識です。
設定例（PHPのphp.ini設定）
; セッションクッキーの設定は、ここをチェック！
session.cookie_httponly = 1 ; JavaScriptからのアクセスを遮断
session.cookie_secure = 1 ; HTTPS通信のみを許可
session.cookie_samesite = “Lax” ; CSRF対策にもなる重要な設定
—
最後に：完璧なセキュリティなんて存在しない
ここまで読んでくださったあなたは、もう「鍵を交換する」という重要な概念を理解しました。
しかし、セキュリティの世界で一番怖いのは「これだけやっておけば絶対安心だ」という油断です。攻撃者は常に新しい抜け穴を探しています。だからこそ、私たちは「攻撃者は必ず穴を見つけてくる」という前提で、多層的な防御を積み重ねていくのです。
最初は難しく感じるかもしれません。でも、一つずつコードを書き、設定を確認していく。その丁寧な積み重ねこそが、あなたが作ったサービスを使うユーザーを守る唯一の盾になります。
これからも、一緒に一歩ずつ学んでいきましょう。現場で困ったことがあれば、またいつでも聞きに来てくださいね！
コメント