【実務・中級編】不適切な乱数生成によるセッションID予測攻撃 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

セッションハイジャックの入り口：その「乱数」は、攻撃者に読まれているかもしれない

やあ。現場でコードを書いている諸君、今日もセッション管理の実装で頭を悩ませているか？

Webアプリケーションの根幹を支える「セッションID」。これが漏洩したり、推測されたりすることは、鍵をドブに捨てるのと同じことだ。たまに、「自前でユニークなIDを作ろう」と工夫するエンジニアがいるが、その工夫こそが最大の脆弱性になるということを知っておいてほしい。

今回は、多くのエンジニアが見落としがちな「不適切な乱数生成によるセッションID予測攻撃」について、現場の視点から深掘りする。

なぜ rand() や mt_rand() を使ってはいけないのか

多くの開発者が陥る罠は、PHPの rand() や mt_rand()、あるいはJavaScriptの Math.random() を使ってセッションIDを生成してしまうことだ。

なぜこれらが危険なのか？答えは簡単だ。これらは「暗号学的に安全（Cryptographically Secure）」ではないからだ。

これらの関数は、計算速度を優先するために設計された「擬似乱数生成器（PRNG）」だ。ある程度の数の乱数サンプルさえあれば、内部状態を逆算できてしまう。つまり、攻撃者は過去に発行されたセッションIDの履歴から、「次に発行されるID」を数式で予測できるということだ。

攻撃シナリオ：予測のメカニズム

1. 観測: 攻撃者はサイトを数千回リロードし、発行されたセッションIDを収集する。
2. 解析: 収集したIDをツール（php_mt_seedのようなツールが有名だ）に食わせる。
3. 予測: 内部状態（シード値）が特定され、次に生成されるセッションIDが導き出される。
4. ハイジャック: 予測したIDを自身のCookieにセットしてリクエストを投げれば、ログイン中のユーザーになりすますことができてしまう。

「コピペで終わらせない」CSPRNGの実装

我々エンジニアが使うべきは、CSPRNG（暗号学的に安全な擬似乱数生成器）だ。OSが提供するエントロピー源（ /dev/urandom 等）を利用するため、予測は不可能に近い。

以下に、実務でそのまま使える「セキュアなID生成」の実装例を示す。

PHPでのセキュアな実装例

PHP 7以降であれば、random_bytes() を使うのが鉄則だ。mt_rand() は二度と使わないように。

<?php
/**
 * セキュアなセッションIDを生成するヘルパー関数
 * bin2hexで16進数に変換し、URLセーフにする
 */
function generateSecureSessionId(int $length = 32): string {
    try {
        // random_bytesはCSPRNGを使用する
        $bytes = random_bytes($length);
        return bin2hex($bytes);
    } catch (Exception $e) {
        // 乱数生成器が利用不可の場合は即座に停止する
        throw new RuntimeException("セッションID生成に失敗しました: " . $e->getMessage());
    }
}

// 実行例
$sessionId = generateSecureSessionId();
echo "生成されたID: " . $sessionId;

Pythonでの実装例

Pythonでは secrets モジュールを使う。これは暗号論的に強力な乱数を生成するために設計されている。

import secrets

def generate_secure_token():
    # 32バイトのトークンをURLセーフな文字列として生成
    return secrets.token_urlsafe(32)

# 実行例
print(f"生成されたトークン: {generate_secure_token()}")

インフラ層での防御：設定ファイルで追い打ちをかける

コードレベルでの修正はもちろん必須だが、Webサーバーの設定でも多層防御を敷くことが、真のプロフェッショナルというものだ。

NginxでセッションCookieの堅牢性を高める設定例を挙げる。HttpOnly や Secure 属性、そして SameSite 属性の強制は必須だ。

# nginx.conf または 各サイトの設定ファイル
# セッションCookieに対するセキュリティヘッダーの強化例
location / {
    # Cookie属性を強制的に付与（アプリケーション側の設定漏れをカバー）
    # HttpOnly: JavaScriptからのアクセス禁止
    # Secure: HTTPS通信のみ許可
    # SameSite=Lax/Strict: CSRF対策
    add_header Set-Cookie "SessionID=$session_id; HttpOnly; Secure; SameSite=Lax";
}

最後に：なぜ「泥臭い確認」が必要なのか

技術的に正しいコードを書くことは、プロとして当然の義務だ。しかし、インシデントは常に「想定外の場所」から発生する。

開発環境のライブラリ: 古いレガシーコードに mt_rand() が隠れていないか？
フレームワークのデフォルト設定: session.entropy_file は適切に指定されているか？
サードパーティ製ツール: 独自に乱数を使っているプラグインはないか？

これらを一つずつ grep で洗い出し、検証する泥臭い作業こそが、強固なシステムを支えている。

「動けばいい」という考えは、攻撃者にとっては「穴だらけです」という招待状に等しい。今日からコードをコミットする前に、その乱数が本当に信頼に足るものか、もう一度立ち止まって考えてみてほしい。

もし、今君のプロジェクトで乱数生成に少しでも不安があるなら、まずは random_bytes() への置き換えから始めよう。それが、防衛戦の第一歩だ。