【実務・中級編】セッション固定攻撃（Session Fixation）の防止策 – アプリケーションセキュリティ & 安全な開発防御ガイド

セッション固定攻撃（Session Fixation）を「過去の遺物」にする：現場で通用する防御の鉄則

現場でインシデント対応をしていると、いまだに「セッション管理はフレームワーク任せだから大丈夫」と油断しているエンジニアに出会うことがある。だが、フレームワークのデフォルト設定を理解せず、セッションのライフサイクルを制御していないアプリは、脆弱性を「隠し持っている」のと同じだ。

今日は、攻撃者がいとも簡単にセッションをハイジャックする「セッション固定攻撃」について、その泥臭い手口と、今日から即座に適用できる実装の極意を伝授しよう。

—

1. 攻撃の構図：なぜ「ログイン前」が狙われるのか

セッション固定攻撃の恐ろしさは、攻撃者が「自分の知っているセッションID」を被害者に押し付け、そのIDをログインによって「有効化」させる点にある。

1. 罠の設置: 攻撃者が自身のブラウザで対象サイトにアクセスし、サーバーから発行された有効なセッションID（例: SID=123）を取得する。
2. IDの注入: 攻撃者は「https://example.com/?SID=123」のようなURLを細工し、ターゲットに踏ませる（あるいはクロスドメインの脆弱性を突き、Cookieを強制セットする）。
3. ログイン: ターゲットがそのリンク経由でログインすると、サーバーは「SID=123 は有効なまま」で認証状態に遷移させてしまう。
4. 乗っ取り: 攻撃者は自分のブラウザで SID=123 をセットしたままリロードする。すると、ターゲットの権限でログイン済みの画面が目の前に現れる。

これは技術的なバグというより、「認証前後でセッションIDを使い回す」という設計上の甘さを突いた典型的な攻撃だ。

—

2. 実装の鉄則：ログイン時に「セッションIDを殺す」

防御の鍵はただ一つ。「ログイン成功の直後に、現在のセッションを破棄し、新しいIDを発行すること」。これに尽きる。

PHPでのセッション再生成（実務コード）

PHPの場合、session_regenerate_id(true) を呼び出すのが黄金律だ。true を指定することで、古いセッションデータがサーバーから確実に削除される。

Python (FastAPI/Flask) でのヒント

フレームワークを使う場合も同様だ。FastAPIであれば、ログイン成功時に現在のセッションクッキーをクリアし、新しいクッキーをレスポンスヘッダーで発行する設計にする。

FastAPIでのセッション再生成の概念
from fastapi import Response

@app.post(“/login”)
async def login(response: Response, user: User):
# …認証ロジック…

# ログイン成功時
# 新しいセッションIDを生成し、Cookieを上書き設定する
new_session_id = generate_secure_token()
response.set_cookie(
key=”session_id”,
value=new_session_id,
httponly=True, # JSからのアクセスを禁止
secure=True, # HTTPS必須
samesite=”Lax” # CSRF対策も忘れずに
)
return {“message”: “Logged in”}

—

3. インフラ・設定で畳み掛ける（防御の多層化）

コードレベルの対策に加え、Webサーバーやブラウザの機能で「逃げ道」を塞ぐのが、プロのインフラエンジニアの仕事だ。

Nginx/App構成でのヘッダー設定

セッションIDが漏洩しても悪用されないよう、Cookie属性を厳格に管理する。

Nginxの設定例：Cookieの漏洩防止
すべてのSet-Cookieヘッダーに対して属性を付与する設定が望ましい
proxy_cookie_path / “/; HTTPOnly; Secure; SameSite=Lax”;

HttpOnly: JavaScriptから document.cookie でセッションIDを盗まれないようにする。XSS対策としても必須。
Secure: 暗号化された通信（HTTPS）以外ではセッションIDを送信させない。
SameSite=Lax/Strict: 外部からのリクエストでセッションIDが送信されるのを防ぐ。

—

4. 最後に：現場で「これだけは守れ」

セキュリティ対策において、最も危険なのは「一度実装したから大丈夫」という慢心だ。以下のチェックリストをチームのPR（プルリクエスト）の指針に加えてほしい。

1. ログイン成功時、確実にIDが変わっているか？（Burp Suite等のプロキシツールでログイン前後のIDを比較確認せよ）
2. ログアウト時にはセッションを完全に破棄しているか？（session_destroy() を呼ぶだけで満足せず、クッキーの生存期間をマイナスにするのがベストだ）
3. セッションのタイムアウト時間は適切か？（放置された端末からの乗っ取りを防ぐため、長時間操作がないセッションは自動破棄する設計になっているか）

セッション固定攻撃は、古典的だが「ログイン」という最も重要な境界線を狙う攻撃だ。ここを完璧に守ることは、ユーザーの信頼を守ることと同義である。

さあ、今すぐコードベースを確認し、ログイン処理の中に session_regenerate_id が存在するかチェックしてほしい。もし無ければ、それが今日君が修正すべき最優先のタスクだ。