【実務・中級編】セッション固定化攻撃(Session Fixation)の防止策 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

セッション固定化攻撃（Session Fixation）を「過去の遺物」にする：現場で生き残るためのセッション管理術

やあ。ペネトレーションテストの現場で、未だに「ログイン直後のセッションIDが変わらない」という致命的な脆弱性に遭遇することがある。これを見つけたとき、攻撃者側としては思わずガッツポーズをしたくなるね。

セッション固定化攻撃は、Webセキュリティの歴史の中でもかなり古い部類に入るが、実装のわずかな妥協が命取りになる。今日は、教科書的な「属性を付けろ」という話から一歩踏み込み、なぜそれが攻撃を封じ込めるのか、そして現場でミスを犯さないための「鉄壁の定石」を叩き込む。

—

1. 攻撃者が狙う「ログインの隙間」

セッション固定化攻撃のメカニズムはシンプルだ。攻撃者は、正当なユーザーに「自分が知っているセッションID」をあらかじめ押し付けておく。

1. 罠の設置: 攻撃者が標的サイトにアクセスし、発行されたセッションIDを盗み出す。
2. 誘い込み: 攻撃者はそのIDをURLパラメータやリンクに埋め込み、被害者に踏ませる（http://example.com/?PHPSESSID=attacker_id）。
3. 固定化: 被害者がそのIDを使ってログインする。すると、そのIDは「認証済み」の状態に昇格する。
4. 乗っ取り: 攻撃者は先ほど仕込んだIDでサイトにアクセスし、被害者のアカウント権限をそのまま奪い取る。

この攻撃の恐ろしい点は、「被害者が正規のログイン手順を踏んでいるにもかかわらず、そのログインの過程でセッションIDが汚染される」という点だ。

—

2. 鉄則：ログイン前後でIDを「再生成」する

最大の防御策は、「認証が成功した瞬間に、既存のセッションIDを破棄し、新しいIDを発行する」ことだ。これを忘れると、どんなに強固な暗号化をしていても意味がない。

PHPでのセッション再生成（実戦サンプル）

PHPの場合、ログイン処理の冒頭で session_regenerate_id(true) を呼ぶのが絶対のルールだ。

<?php
// ログイン認証成功後の処理
session_start();

// 既存のセッションIDを破棄し、新しいIDを生成する
// 第1引数に true を渡すことで、古いセッションデータそのものを削除し、
// セッションハイジャックのリスクを排除する
session_regenerate_id(true);

// 認証後のユーザー情報をセッションに格納
$_SESSION['user_id'] = $user_id;
$_SESSION['authenticated'] = true;

// この後、ログイン後のトップページへリダイレクトさせる
header('Location: /dashboard.php');
exit;
?>

—

3. クッキー属性の「三種の神器」を徹底する

サーバー側でIDを再生成しても、ブラウザ側での管理が甘ければ攻撃者の付け入る隙ができる。以下の属性は、現代のWebアプリケーションでは「デフォルトで設定されていて当たり前」のものだ。

HttpOnly: JavaScriptによるクッキーへのアクセスを禁止する。XSS（クロスサイトスクリプティング）が起きた際、セッションIDを抜き取られるリスクを劇的に下げる。
Secure: HTTPS通信時のみクッキーを送信する。中間者攻撃によるID窃取を防ぐ。
SameSite=Lax (または Strict): CSRF対策。外部サイトからのリクエスト時にセッションクッキーが送信されるのを抑制する。

Nginxでのヘッダー強制設定（インフラ層での防御）

アプリケーションコードの修正漏れを防ぐため、リバースプロキシ（Nginx）側でも強制的にセッションクッキーを保護する設定を入れておこう。

# Nginx設定ファイル /etc/nginx/conf.d/security.conf
# セッションクッキーに強制的に属性を付与する
# 注意: PHP等で session_set_cookie_params を適切に設定していれば
# ここでの設定は冗長だが、多層防御として非常に有効だ
proxy_cookie_path / "/; HTTPOnly; Secure; SameSite=Lax";

—

4. 現場でやってはいけない「NG事例」

最後に、私がペネトレーションテストの報告書でよく指摘する「勘違い」を列挙しておく。

URLへのセッションID埋め込みを許可する: php.ini の session.use_trans_sid が有効になっていないか確認しろ。これが有効だと、URLパラメータにセッションIDが露出する。現代のWebでこれを有効にする正当な理由はない。
認証チェックの漏れ: ログイン後のページで「セッション変数が存在するか」だけを確認し、「認証済みフラグ」をチェックしていないケース。これでは、固定化されたIDでアクセスした際に、単にログイン画面をスキップされる可能性がある。

認証チェックの理想的な実装例（PHP）

// 各ページの先頭で呼び出すべき認証チェック
function check_auth() {
    session_start();
    
    // 認証フラグの確認
    if (!isset($_SESSION['authenticated']) || $_SESSION['authenticated'] !== true) {
        header('Location: /login.php');
        exit;
    }

    // IPアドレスやユーザーエージェントの検証（補完的な対策）
    // 大規模な攻撃にはこれだけでは不十分だが、簡易的な検知にはなる
    if ($_SESSION['user_agent'] !== $_SERVER['HTTP_USER_AGENT']) {
        session_destroy();
        header('Location: /login.php');
        exit;
    }
}

—

結論：エンジニアとしての矜持

セッション管理は地味だ。しかし、ここを疎かにすれば、どんなに豪華なUIも、複雑なビジネスロジックも、たった一行の脆弱性で全てが水の泡になる。

「ログインしたらIDを変える」。この当たり前のことを、当たり前にコードに落とし込めるかどうか。それが、プロのエンジニアと、そうでないエンジニアの分かれ道だ。もし君のプロジェクトでこの再生成が行われていない箇所を見つけたら、すぐにチケットを切り、修正を命じてくれ。それが、ユーザーを守るための最初の一歩だ。

健闘を祈る。また現場で会おう。