セッション固定化攻撃（Session Fixation）を根絶する：ログインの「儀式」を怠るな
現場でインシデント対応をしていると、意外なほど見かけるのが「ログイン前後のセッションIDの使い回し」だ。最新のフレームワークを使っているから大丈夫だと思い込んでいる君たちへ、あえて言おう。それは「鍵をかけずに玄関を開けているのと同じ」だ。
今日は、XSSで奪われるセッションIDの恐怖と、それを無効化する最も泥臭く、そして最も確実な「セッション再生成」の作法を叩き込む。
—
なぜ「セッション固定化」が命取りなのか
セッション固定化攻撃の仕組みはシンプルだ。攻撃者はまず自分の端末で有効なセッションIDを取得し、それを標的のユーザーに何らかの方法（URLパラメータへの埋め込みなど）で送りつける。ユーザーがそのIDを使ってログインすると、バックエンドは「認証済み」としてそのIDを昇格させる。
攻撃者は、自分が最初に手に入れたIDを使って、そのままユーザーの権限でシステムに潜り込む。「IDがログイン前後で変わらない」という仕様の穴を突かれるだけで、認証は無力化されるんだ。
—
現場で即効性のある「セッション再生成」の実装
多くのWebフレームワークは、ログイン処理の直後にセッションを再生成する関数を用意している。これを「ログイン成功時の儀式」としてルール化しよう。
PHPでの実装例
PHPでは、ログイン処理の直後に session_regenerate_id(true) を呼び出すのが鉄則だ。true を指定することで、古いセッションデータがサーバーから完全に削除される。
Python (Flask) での実装例
Flaskなどの軽量フレームワークでは、ログイン処理で明示的にセッションをクリアし、再設定を行う必要がある。
from flask import session
def login_success(user_id):
# 既存のセッションデータを完全にクリアしてから再構築
session.clear()
# 新しいセッションとして再設定
session[‘user_id’] = user_id
session.permanent = True # 永続セッションの設定
—
「XSS」と「セッションハイジャック」の悪夢のシナリオ
セッションIDを再生成していても、XSS（クロスサイトスクリプティング）が放置されていれば、結局IDは盗まれる。
反射型や格納型XSSでJavaScriptが実行されると、攻撃者は document.cookie を読み取り、セッションIDを外部サーバーに送信する。このとき、セッションIDに HttpOnly フラグが付いていないと、JavaScriptからIDにアクセスできてしまう。
防御策：Cookieへの強固なガード（Nginx/Webサーバー設定）
コードだけでなく、インフラ層での防御が最後の砦だ。以下のような設定をWebサーバー側で行い、Cookieの漏洩を物理的に防ぐ。
Nginx設定ファイル (nginx.conf)
セッションCookieに対するセキュリティヘッダーの強制
HttpOnly: JavaScriptからのアクセス禁止
Secure: HTTPS通信のみ許可
SameSite=Lax: CSRF対策としてクロスサイトでのCookie送信を抑制
location / {
proxy_cookie_path / “/; HttpOnly; Secure; SameSite=Lax”;
}
—
最後に：セキュリティは「性悪説」で設計せよ
後輩のエンジニアから「この設定、本当に必要ですか？」と聞かれることがよくある。僕の答えはいつも一つだ。「攻撃者は、君が読み飛ばした一行のコードを狙っている」。
1. ログイン直後に session_regenerate_id(true) を呼ぶ。
2. Cookieには必ず HttpOnly, Secure, SameSite を付与する。
3. XSSを許さないコードを書く（エスケープ処理の徹底）。
これらはセキュリティの基本中の基本だが、これさえ完璧にこなしているシステムは、実は驚くほど少ない。教科書を眺めるだけでなく、自分の書いたコードが「攻撃者の視点からどう見えるか」を常に想像してほしい。それができるエンジニアこそが、真のプロフェッショナルだ。
次のインシデント対応で君の名前を見なくて済むよう、今日からこの実装を徹底してくれ。期待している。
コメント