【入門編】 セッション固定化攻撃(Session Fixation)の防止とセッションIDの再生成 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！ITインフラやセキュリティの世界へようこそ。
これからWeb開発やシステムの保守を担当する新人エンジニアの皆さん、日々の業務本当にお疲れ様です。

セキュリティの勉強を始めると、「セッション固定化攻撃」や「CookieのSecure属性」など、なんだか難しそうな言葉がたくさん出てきて頭が痛くなりますよね。でも、安心してください。一つひとつの仕組みは、私たちの日常生活にある「防犯の知恵」とまったく同じなんです。

今回は、Webアプリケーションを守るための超重要テーマである「セッション固定化攻撃の防止」と「Cookieの安全な設定」について、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！

—

1. 家の鍵で例える「セッション」と「セッションID」の仕組み

まずは、Webサイトで私たちが「ログイン」するときに何が起きているのかをイメージしてみましょう。

皆さんがお出かけするとき、家の玄関に鍵をかけますよね。そして帰ってきたときには、自分の持っている合鍵でそのドアを開けて中に入ります。
Webの世界でもこれと全く同じことが行われています。

  • セッション（Session）：あなたがWebサイトにログインしてからログアウトするまでの「滞在期間（お部屋の中にいる時間）」のことです。
  • セッションID（Session ID）：あなたがそのお部屋の正当な住人であることを証明する「合鍵（または入場パスポート）」のようなものです。

通常、私たちがIDとパスワードを入力してログインすると、Webサーバーは「はい、あなたはこのユーザーですね」と確認し、あなた専用の合鍵（セッションID）を一つ発行して渡してくれます。
それ以降、ブラウザはその合鍵をこっそりポケット（Cookie）に入れて持ち歩き、ページを移動するたびにサーバーへ「ほら、この合鍵を持っていますよ」と見せることで、ログイン状態を維持しているんです。

—

2. セッション固定化攻撃（Session Fixation）の恐ろしい手口

ここで、今回の主役である「セッション固定化攻撃」のメカニズムを、ちょっとずる賢い泥棒の例えで見てみましょう。

泥棒の手口：あらかじめ「自分の鍵」を渡しておく

1. 下準備：攻撃者（泥棒）は、ターゲットにするWebサイトにアクセスし、サーバーから自分用の「合鍵A（セッションID）」をあらかじめ取得します。
2. 罠を仕掛ける：攻撃者は、その「合鍵A」を何らかの手段（メールのリンクや悪意ある掲示板など）を使って、ターゲットのユーザーに踏ませます。

  • 「このお得なキャンペーンページを見て！」と言って、URLのパラメータにこっそり合鍵Aの情報を混ぜて踏ませるのが古典的な手口です。

3. ユーザーがログインする：ユーザーはその罠のリンクを踏んでWebサイトを開き、何も知らずに自分のIDとパスワードを入力して「ログイン」します。
4. 犯罪成立：もしWebサイトの作りが甘いと、サーバーは「ユーザーがログインしたけれど、手元にある合鍵A（攻撃者が用意したもの）をそのまま使い続けよう」と判断してしまいます。

結果どうなるでしょうか？
ユーザーは無事にログインできたつもりでいますが、そのお部屋の鍵は、最初に攻撃者が用意した「合鍵A」のままです。攻撃者は、自分が持っているもう一つの合鍵Aを使って、後からそのユーザーの部屋に合影もせずに入り込み、クレジットカード情報や個人情報を盗み見ることができてしまうのです。これがセッション固定化攻撃の恐ろしい仕組みです。

—

3. 最大の防御策：ログイン前後で「セッションIDを再生成する」

この泥棒の手口を防ぐための決定的な対策が、今回最も覚えてほしい「ログイン前後でのセッションIDの再生成」です。

現実の世界で考えてみてください。
泥棒にあらかじめ「合鍵A」を渡されていたとしても、あなたが部屋に入ってドアを閉めた瞬間、管理人がやってきて「お客様、防犯のために鍵を別の新しいもの（合鍵B）に差し替えました！これからはこちらの新しい鍵をお使いください」と鍵をごっそり取り替えてくれたらどうでしょう？

泥棒が持っていた「合鍵A」は、もう使い物にならなくなりますよね。これと同じことをWebシステムで行うのがセッション再生成です。

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

ログイン処理を実装する際は、ユーザーが正しいID/パスワードを入力して認証に成功した直後に、必ず session_regenerate_id(true) という関数を呼び出します。

<?php
// 1. ユーザーからの入力を受け取る
$username = $_POST['username'] ?? '';
$password = $_POST['password'] ?? '';

// 2. データベース等でユーザー認証を行う（架空の関数）
if (isValidUser($username, $password)) {
    
    // 【超重要】セッション固定化攻撃を防ぐため、ログイン成功直後にセッションIDを新しく作り直す！
    // 引数に true を指定することで、古いセッションデータ（攻撃者が仕込んだものなど）を完全に破棄します。
    session_regenerate_id(true);

    // 3. セッションにログイン済みのユーザー情報を保存する
    $_SESSION['login_user'] = $username;
    
    // 4. マイページ等へリダイレクト
    header('Location: /mypage.php');
    exit;
} else {
    // 認証失敗時の処理
    echo "ログインに失敗しました。";
}
?>

このように、「ログインの前後でセッションIDを必ず新しいものに生まれ変わらせる」。たったこれだけの処理で、セッション固定化攻撃は完全に防ぐことができます。

—

4. 泥棒から合鍵を守る！Cookieの3大セキュリティ属性

セッションIDを新しくすることに加えて、ブラウザがその合鍵（セッションID）を安全に保管できるように、Cookie自体にも頑丈な鍵をかけてあげる必要があります。

それが、Cookieに設定する以下の3つの属性です。

1. Secure属性
2. HttpOnly属性
3. SameSite属性

それぞれの意味と設定方法を、優しく見ていきましょう。

① Secure属性（通信の盗聴を防ぐ）

  • 意味：「この合鍵は、暗号化された安全な通信（HTTPS）のときだけ持ち歩いてね」という指示です。
  • なぜ必要？：もしWebサイトが暗号化されていない「HTTP」のままだと、カフェのWi-Fiなどの公衆回線で、悪意ある第三者に通信を丸パクリ（盗聴）され、セッションIDをそっくりそのまま盗まれてしまいます。
  • 対策：本番環境では必ずHTTPSを導入し、Cookieに Secure 属性を付与しましょう。

② HttpOnly属性（JavaScriptからの盗難を防ぐ）

  • 意味：「この合鍵はブラウザの画面側（JavaScript）からは絶対に触らせないでね」という鉄のガードです。
  • なぜ必要？：Webサイトにクロスサイトスクリプティング（XSS）などの脆弱性があり、攻撃者に悪意あるスクリプトを実行された場合、document.cookie というプログラムを書かれてセッションIDがごっそり盗まれてしまう危険があります。
  • 対策：HttpOnly を有効にすることで、JavaScriptからCookieへのアクセスを物理的にブロックし、万が一のXSSによるセッション乗っ取り被害を最小限に抑えます。

③ SameSite属性（悪意ある外部サイトからの不正利用を防ぐ）

  • 意味：「別の怪しいWebサイトからリンクを踏まされたとき、この合鍵を勝手に送信しないでね」というルールです。
  • なぜ必要？：これはCSRF（クロスサイト・リクエスト・フォージェリ）や不正なリクエストを防ぐためにあります。
  • 設定値：基本的には、厳格にリクエスト元をチェックしてくれる SameSite=Lax または Strict を指定するのが現代の標準です。

—

5. 実務でそのまま使える！PHPでのCookie設定サンプル

それでは、これらの安全な属性をすべて盛り込んだCookieの設定方法を、PHPのコードで見てみましょう。

PHPでは、session_set_cookie_params() という関数を使うことで、セッションIDを保存するCookieに対して、一括で安全な属性をセットすることができます。

<?php
// セッションを開始する「前」に、Cookieのセキュリティパラメータを設定します。

$cookieParams = [
    'lifetime' => 0,                      // ブラウザを閉じたらセッションを破棄する
    'path'     => '/',                      // サイト全体のどのページでも有効にする
    'domain'   => 'example.com',            // 自社のドメインを指定する
    'secure'   => true,                     // 【Secure属性】HTTPS通信の時のみCookieを送信する
    'httponly' => true,                     // 【HttpOnly属性】JavaScriptからのアクセスを禁止し、XSS対策にする
    'samesite' => 'Lax'                     // 【SameSite属性】外部サイトからの不審なリクエスト時にCookie送信を抑制する
];

// 設定を適用する
session_set_cookie_params($cookieParams);

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

フレームワーク（LaravelやSymfony、Rails、Djangoなど）を使用している場合も、設定ファイル（config/session.php など）の中に必ずこれらのフラグ（secure, http_only, same_site）を true にする項目が用意されています。開発の際は、初期値のままで満足せず、必ずこれらのフラグが有効になっていることを確認してくださいね。

—

6. まとめ：安全なWebアプリケーション開発への第一歩

お疲れ様でした！今回は少し専門的な言葉も出てきましたが、要するに大切なポイントは以下の2つだけです。

1. ログインが成功した瞬間、必ず session_regenerate_id(true) でセッションIDを新しく作り直すこと。
2. セッションIDを預けるCookieには、Secure・HttpOnly・SameSite の3つの防犯ロックを必ずかけること。

セキュリティの対策は、一度覚えてしまえばどんなシステム開発にも共通して使える強力な武器になります。「なぜこの設定が必要なんだっけ？」と迷ったときは、今日の「家の合鍵と泥棒の話」をぜひ思い出してみてください。

一歩ずつ、確実に安全なコードを書けるエンジニアを目指して一緒に頑張っていきましょう！皆さんの素晴らしい開発ライフを応援しています。

スポンサーリンク

コメント

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