【実務・中級編】セッション固定化攻撃(Session Fixation)を防ぐログイン後のID再生成 – アプリケーションセキュリティ & 安全な開発防御ガイド

現場でコードレビューをしていると、未だに「ログイン処理の最後でセッションIDを更新していない」というケアレスミスに遭遇する。正直に言おう。これは「玄関の鍵を閉めずに泥棒を招待している」のと同じだ。

今日は、OWASP Top 10でも常連の「セッション固定化（Session Fixation）」について、教科書的な説明はすっ飛ばして、なぜ攻撃者がここを狙うのか、そしてどうコードを修正すべきかを、現場のリアリティを持って解説する。

—

想像してほしい。攻撃者はまず、ターゲットのWebサイトにアクセスし、自身が発行された「有効なセッションID」を手にいれる。次に、ターゲットにそのIDを送りつける（URLパラメータに含めたり、SNSで偽のリンクを踏ませたりする）。

ターゲットがそのリンクからログインすると、サーバー側がログイン前のセッションIDを使い回している場合、攻撃者は「認証済み」のセッションを奪取できてしまう。

攻撃者は、ターゲットがログインした瞬間に、ターゲットになりすまして個人情報を抜き取ったり、権限を悪用したりできるわけだ。ログインという「認証の壁」を突破するのに、パスワードすら必要ない。これがセッション固定化の恐怖だ。

—

対策はシンプルだ。「ログイン成功直後、古いセッションIDを破棄し、新しいIDを発行する」。これだけでいい。

多くのモダンなフレームワークはこれを自動化しているが、レガシーなシステムや自前でセッション管理をしている場合は、明示的なコードが必要になる。

PHPの場合、session_regenerate_id() を使う。ここで重要なのは、古いセッションデータを確実に削除することだ。

Python (Flask) でのセッション再生成

Flaskの場合、session.clear() で一度中身をリセットし、セッションを再生成するのが定石だ。

from flask import session

def login_user(user):
# ログイン成功後
# 古いセッションIDによるなりすましを防ぐためクリア＆再発行
old_session = dict(session)
session.clear()
session.update(old_session)

# 認証情報をセット
session[‘user_id’] = user.id
session.permanent = True

—

アプリ層での実装が基本だが、インフラや設定で「事故」を防ぐ工夫も忘れてはいけない。

セッションIDを運ぶクッキーには、以下の属性を必ず付けること。

PHPの設定例 (php.ini):

; セッションIDのクッキー属性を厳格にする
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = “Lax”

—

多くのエンジニアが「セッション再生成」は実装している。しかし、「パスワード変更時」や「権限昇格時（管理者画面への遷移など）」に再生成を忘れているケースが意外と多い。

もし君が今、既存プロジェクトのコードを読んでいるなら、以下のコマンドでgrepをかけてみてほしい。

プロジェクト内でセッション再生成が適切に行われているか確認
grep -r “session_regenerate_id” ./src/

もしヒットしなければ、そこが君のチームの「脆弱性」だ。

セキュリティとは、完璧を目指すことではない。「攻撃者がコストを割くのを諦めるほど、泥臭く防御を積み上げること」だ。今日紹介したログイン後のID再生成は、その中でも最も投資対効果が高い「鉄則」である。

明日から、いや今すぐ、君のコードベースにこの1行が正しく実装されているか確認してくれ。それが、チームとユーザーを守るための、エンジニアとしての責任だ。