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

こんにちは！Webアプリケーションの開発やインフラの管理、本当にお疲れ様です。
新人のIT担当者さんや、「セキュリティってなんだか難しそうだな…」と感じている開発者さんに向けて、今日からすぐに使える実践的なセキュリティの知識を一緒にお話ししていきますね。

私たちが日々何気なく使っている「ログイン機能」。
IDとパスワードを入力してマイページに入るとき、実は裏側では「セッション」という仕組みが使われています。今回は、このセッションを狙った「セッション固定化攻撃」という少し厄介な手口と、それをピシャリと防ぐためのスマートな対策について、身近な例えを交えながら一歩ずつ学んでいきましょう！

—

1. 「セッション固定化攻撃」ってなに？ 身近な例えで理解しよう

セキュリティの難しい言葉を覚える前に、まずは私たちの日常生活にある「合鍵」の防犯に例えて考えてみましょう。

カフェでの「席取り」に例えてみる想像

よくあるカフェの光景を思い浮かべてください。
あなたは友人とカフェでお茶をしようとお店に入りました。まだ注文はしていませんが、先に席を確保するために、お気に入りの席に「ハンカチ」を置いて場所取りをしましたよね。これが、Webサイトにおける「未ログイン状態のセッションID（一時的な整理券）」です。

さて、もしここで悪意を持った泥棒（攻撃者）がいたらどうなるでしょうか？
泥棒は、あなたがまだ席に戻っていない隙に、その席に置いてあったあなたのハンカチをそっとすり替えて、「あらかじめ自分が用意しておいた、別のハンカチ（攻撃者が用意したセッションID）」に置き換えてしまいました。

あなたが何も知らずに戻ってきて、その席にカバンを置き、スマホを置き、「さあ、のんびりしよう」とくつろぎ始めたとします。
ここで泥棒がお店の人に「あの席の者ですが、追加注文と会計をお願いします」と声をかけたとしましょう。お店の人は「あ、あの席のハンカチの方ですね」と認識してしまい、あなたの個人情報やプライベートな注文情報が、すべて泥棒に紐づいて見えてしまう……これが、セッション固定化攻撃の恐ろしいメカニズムです。

Webの世界に置き換えると、以下のようになります。
1. 攻撃者があらかじめ用意したセッションID（ハンカチ）を、被害者のブラウザに強制的に使わせる（固定させる）。
2. 被害者がそのIDのままログインする。
3. 攻撃者は、あらかじめ自分が仕込んだそのセッションIDを使って、被害者のアカウントになりすましてログイン状態を乗っ取る。

IDやパスワードを盗み出すわけではなく、「ログインした後の合鍵（セッションID）を先に泥棒が決めておく」という、非常に巧妙な手口なんですね。

—

2. 泥棒の侵入を防ぐ！一番大切な「2つの鉄則」

このセッション固定化攻撃を防ぐために、私たち開発者やIT担当者が絶対にやっておかなければならない対策は、実はとてもシンプルです。大きく分けて「2つの鉄則」があります。

鉄則①：ログインの前後で「合鍵（セッションID）」を必ず作り直す！

これが一番の特効薬です。
先ほどのカフェの例で言えば、あなたが注文を済ませて席に座った瞬間、お店の店員さんが「お客様、席の番号札を新しく発行しますね！」と言って、まったく新しい別の席番号（新しいセッションID）をあなたに手渡し、古い番号を無効化するイメージです。

これをしておけば、たとえ攻撃者が事前に古い番号（ハンカチ）を仕込んでいたとしても、ログインが成功した瞬間にその番号はゴミ箱行きになり、まったく新しい安全な番号に切り替わるため、攻撃者はあなたになりすますことができなくなります。これを専門用語で「セッションIDの再生成（Session Regeneration）」と呼びます。

鉄則②：Cookieの「お守り属性」を正しく設定する！

セッションIDは、通常ブラウザの Cookie（クッキー）という仕組みに保存されてサーバーとやり取りされます。この Cookie に、しっかりとした「お守り（属性）」をつけてあげることで、盗み見や不正な改ざんから守ることができます。

具体的には、以下の3つの属性を設定します。

  • Secure 属性: 暗号化された通信（HTTPS）のときだけ Cookie を送受信するように制限します。
  • HttpOnly 属性: 悪意あるJavaScript（クロスサイトスクリプティングなど）から Cookie を読み取られないようにブロックします。
  • SameSite 属性（Lax または Strict）: 外部の悪意あるWebサイトから勝手にリクエストを送られる攻撃（CSRF）を防ぎます。

—

3. 実装で学ぶ！PHPでの安全なセッション管理コード

百聞は一見にしかず。それでは実際に、PHPを使った安全なログイン処理とセッション再生成の実装サンプルを見てみましょう。実務のコードにそのまま組み込めるように、日本語の丁寧なコメントを入れています。

<?php
// セッションを開始する前の安全な設定
// セッションIDの受け渡しにCookieのみを使用し、URLパラメータ経由での漏洩を防ぐ
ini_set('session.use_strict_mode', '1'); // 未初期化のセッションIDの使用を禁止
ini_set('session.use_cookies', '1');
ini_set('session.use_only_cookies', '1');

// クッキー自体のセキュリティ属性を設定する（PHP 7.3以降）
session_set_cookie_params([
    'lifetime' => 0,                      // ブラウザを閉じたらセッション破棄
    'path'     => '/',
    'domain'   => 'example.com',           // 自社のドメインを指定
    'secure'   => true,                    // HTTPS通信でのみCookieを送信する
    'httponly' => true,                    // JavaScriptからのCookieアクセスを禁止
    'samesite' => 'Lax'                    // クロスサイトリクエストの制限
]);

// セッションの開始
session_start();

/**
 * ログイン処理のシミュレーション
 */
$username = $_POST['username'] ?? '';
$password = $_POST['password'] ?? '';

// 仮の認証チェック（実際にはデータベース等でハッシュ化されたパスワードと照合します）
if ($username === 'admin' && $password === 'secret_password') {
    
    // 【最重要！】セッション固定化攻撃を防ぐため、ログイン成功直後にセッションIDを必ず再生成する
    // trueを指定することで、古いセッションデータファイルもサーバー側から完全に削除します
    session_regenerate_id(true);

    // ユーザーがログイン済みであることをセッションに保存
    $_SESSION['user_logged_in'] = true;
    $_SESSION['username'] = $username;

    echo "ログインに成功しました！安全なセッションが発行されました。";
    exit;
} else {
    echo "ログイン失敗：IDまたはパスワードが違います。";
}
?>

コードのポイント解説

ここで注目してほしいのは、認証が成功した直後にある session_regenerate_id(true); という一行です。
この処理を行うことで、ログイン前の「怪しいセッションID」が捨てられ、完全に新しくて綺麗なセッションIDへと生まれ変わります。これさえしっかりと実装しておけば、セッション固定化攻撃の大部分を綺麗に無効化することができます。

—

4. インフラ・フレームワーク設定時のチェックリスト

自社でゼロからPHPなどのプログラムを書く場合だけでなく、世の中の便利なフレームワーク（Laravel、Django、Railsなど）や、CMS（WordPressなど）を使う場合でも、インフラやミドルウェアのレイヤーで同様の対策が有効です。

現場のデプロイやサーバー構築の際に、以下の項目を必ずチェックする習慣をつけましょう。

1. HTTPS化（TLS/SSLの強制）の徹底

  • Secure 属性を有効にする大前提として、サイト全体がHTTPSで暗号化されている必要があります。HTTPのままだと、ネットワークの途中でセッションIDが丸見えになってしまいます。

2. フレームワーク標準のセッション管理機能を使う

  • 独自のセッション管理機能を自作するのはバグの元です。モダンなフレームワークが標準で提供している、ログイン時のセッション再生成機能（Laravelの Auth::login() や request()->session()->regenerate() など）を信頼して利用しましょう。

3. Cookieのフラグ確認

  • ブラウザの開発者ツール（F12キーなど）を開き、[Application]タブや[Storage]タブの[Cookies]から、セッションID（例: PHPSESSID や laravel_session など）に HttpOnly や Secure、SameSite がちゃんとチェックされているか、自分の目で確認する癖をつけると一気にスキルアップできますよ。

—

おわりに：一歩ずつ、安全なWebの世界を作っていきましょう

今回は「セッション固定化攻撃」の仕組みから、カフェの例えを交えた直感的な解説、そして具体的なコードによる対策までをご紹介しました。

「難しそうだな」と感じていたセキュリティの対策も、

  • 「ログインしたら合鍵（セッションID）を作り直す」
  • 「Cookieにお守り属性（HttpOnly/Secure/SameSite）をつける」

という2つのポイントを意識するだけで、ぐっと安全性が高まることがお分かりいただけたかと思います。
実務の中で新しい機能を実装するとき、あるいは設定ファイルを触るときには、「お、ここでセッションの再生成はちゃんと動いているかな？」と、ぜひ今日の話を思い出してみてくださいね。

あなたの書いたコードが、ユーザーの大切なデータを守る強固な盾になります。一歩ずつ、一緒に安全なWebの世界を作っていきましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました