セッションフィクセーションとは？
セッションフィクセーションは、セッション識別子の管理不備を悪用し、攻撃者が正規ユーザーのセッションを乗っ取ることを可能にするWebアプリケーションの脆弱性です。根本的な問題は単純で、ユーザーが認証した際にアプリケーションが新しいセッションIDを割り当てないことにあります。つまり、攻撃者が認証前のセッション識別子を知っている、または制御している場合、その識別子を使って認証済みセッションへ正規ユーザーとしてアクセスできます。
MITRE CWEはこの弱点を次のように定義しています。「ユーザーを認証する、または新しいユーザーセッションを確立する際に、既存のセッション識別子を無効化しない場合、攻撃者は認証済みセッションを盗む機会を得る。」この結果、被害者が何も気付かないまま、ほぼ完全なアカウント乗っ取りが発生します。
セッションフィクセーションはセッションハイジャックとは異なりますが、混同されることがあります。OWASPは明確に区別しています。セッションフィクセーションは被害者がログインする前に始まり、 セッションハイジャックは既に認証済みのアクティブなセッションが存在した後に発生します。フィクセーション攻撃では、攻撃者は既にセッションIDを知っている（自分で設定した）状態です。ハイジャック攻撃では、攻撃者はアクティブなセッションからセッションIDを取得または予測する必要があります。
| 属性 | セッションフィクセーション | セッションハイジャック |
| 攻撃タイミング | 被害者が認証する前 | 被害者が認証した後 |
| セッションIDの知識 | 攻撃者が事前にIDを設定または知っている | 攻撃者がIDを取得または予測する必要がある |
| 主な対策 | ログイン時のセッションID再生成 | トークン暗号化、安全な送信 |
この違いはセキュリティ制御にとって重要です。アプリケーションがログイン後にセッションIDを再生成すれば、フィクセーション攻撃を防げます。トークンを転送時に暗号化するだけではハイジャックは防げても、フィクセーションには無防備です。攻撃の仕組みを理解すれば、この違いがなぜ重要かが分かります。
.jpg)
セッションフィクセーションの仕組み
セッションフィクセーションは、 MITRE CWEおよび OWASP WSTGの両方で文書化されている4段階の攻撃フローに従います。
- ステップ1：セッション取得。 攻撃者が対象アプリケーションにアクセスし、認証前の有効なセッションIDを受け取ります。例えば、サーバーが
JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1を返す場合があります。許容的なセッション受け入れメカニズムを持つアプリケーションでは、攻撃者が任意のセッションID値を指定しても、アプリケーションはそれを無条件で受け入れます。 - ステップ2：セッション配布。 攻撃者は既知のセッションIDを被害者に配布します。これは細工されたURL、クロスサイトスクリプティングペイロード、挿入されたMETAタグ、HTTPレスポンススプリッティングなどで行われます。目的は単純で、被害者のブラウザが攻撃者制御のセッションIDを使って対象アプリケーションへアクセスさせることです。
- ステップ3：被害者の認証。 被害者が細工されたリンクをクリックするか、攻撃者の配布メカニズム経由でアプリケーションにアクセスし、通常通りログインします。アプリケーションは認証情報を検証し、アクセスを許可しますが、ログイン成功時にセッションIDを再生成せず、攻撃者が既に知っている識別子のまま動作を続けます。
- ステップ4：アカウント乗っ取り。 攻撃者は既知のセッションIDを使ってアプリケーションにリクエストを送信します。サーバーはこれらのリクエストを認証済み被害者からのものとして扱います。MITREは「セッションの存続期間中、被害者アカウントへのほぼ無制限のアクセスを提供する」と指摘しています。
この4つの基本ステップ以外にも、攻撃者のアクセス権や対象アプリケーションの構成に応じて、セッションフィクセーションは複数の異なる手法で実行されます。
主な5つの攻撃ベクトル
- URLパラメータインジェクションは最も単純なベクトルです。攻撃者はセッションIDをURLクエリパラメータとして埋め込み、フィッシングやメールでリンクを配布します：
https://vulnerable-app.com/login?sessionid=ATTACKER_KNOWN_ID。 Burp Scannerは「Session token in URL」をCWE-384として分類しています。 - XSSによるCookieインジェクションは、被害者のブラウザで実行されるJavaScriptを使ってセッションクッキーを設定します：
document.cookie = "sessionid=ATTACKER_KNOWN_ID";。MITREは クロスサイトスクリプティングがセッションフィクセーションペイロード配布の2大手法の1つであると確認しています。 - METAタグインジェクションは、ブラウザにクッキーを設定するHTMLタグを埋め込みます：
<meta http-equiv="Set-Cookie" content="sessionid=ATTACKER_KNOWN_ID">。 OWASPはこの手法がJavaScriptインジェクションより対策が難しいとし、「ブラウザでこれらのタグの処理を無効化することは不可能」と述べています。 - HTTPレスポンスヘッダーインジェクションは、レスポンススプリッティング脆弱性を悪用し、
Set-Cookieヘッダーをサーバーレスポンスに直接挿入し、クライアント側スクリプトなしで制御下のセッションIDを植え付けます。 - クロスサブドメインCookieフィクセーションは、共有ドメイン構成を悪用します。MITREはこれを直接文書化しています。
bank.example.comとrecipes.example.comが同じトップレベルドメインを共有している場合、recipesアプリケーションの脆弱性が、example.com配下の全アプリケーションで使われるセッションIDを固定できます。配布ベクトルの多様さが、実運用システムでセッションフィクセーションが依然として見られる理由です。
セッションフィクセーションの原因
セッションフィクセーションの根本原因は十分に文書化されており、それぞれが開発チームで対策可能なギャップを示しています。
認証後のセッションID再生成の失敗
これは本記事で引用されている全ての権威ある情報源が挙げる主因です。 OWASPガイドは「アプリケーションがユーザー認証後にセッションクッキーを更新しない場合、セッションフィクセーション脆弱性が存在する可能性がある」と明記しています。
OWASPシートは、ログイン、パスワード変更、権限レベル変更、ロール遷移時にセッションID再生成が必須であると規定しています。 CVE-2022-24895の記録では、SymfonyのNONEセッションマイグレーション戦略が認証後も同じセッションを維持し、フィクセーション攻撃を可能にし、高い深刻度評価となっています。
許容的なセッションID受け入れ
OWASP Session Management Cheat Sheetは、セッションIDの取り扱いに2つのメカニズムを定義しています。許容的メカニズムは、ユーザーが設定した任意のセッションID値を有効として受け入れ、それに対して新しいセッションを作成します。厳格なメカニズムは、アプリケーションが生成したセッションIDのみを受け入れます。許容的メカニズムを使うと、攻撃者はサーバー発行IDを取得せずとも任意値を植え付けられます。
予測可能なセッション識別子
MITREは、予測可能なセッション識別子を CWE-340（予測可能な数値や識別子の生成）に関連する要因として挙げています。セッションIDがパターン化されていたり、乱数性が弱い場合、攻撃者はサーバーから取得せずとも有効な値を予測できます。
許容的なクッキードメインスコープ
Domainクッキー属性をトップレベルドメイン、例えばDomain=example.com（Domain=app.example.comではなく）に設定すると、全サブドメインでクッキーが送信されます。いずれかのサブドメインの脆弱性が、同一ドメイン配下の全アプリケーションのフィクセーション入口となります。
HTTPからHTTPSへの遷移時のセッション再生成の欠如
OWASP WSTG-SESS-03はこの特定シナリオを指摘しています。HTTPでセッション識別子を発行し、その後HTTPSログインフォームへリダイレクトし、認証時にセッションIDを再発行しないサイトは、認証前IDをネットワークレベルで盗聴されるリスクがあります。攻撃者は安全でない接続でIDを取得し、被害者の認証を待ちます。これらの原因は単独で現れることは稀であり、標準化団体がどのように正式分類しているかを理解することで、対策の優先順位付けや説明が容易になります。
OWASPによるセッションフィクセーションの分類
セッションフィクセーションは、MITRE Common Weakness Enumeration、OWASP Top 10、OWASP Web Security Testing Guideという3つの権威ある標準体系で正式に分類されています。OWASP A07では、認証制御の失敗カテゴリに位置付けられ、同じ対策範囲を持つ関連弱点と並びます。それぞれの分類は異なる対象者に向けられ、異なるアクションを示唆します。
CWE-384：正式な弱点識別子
MITRE CWE-384はセッションフィクセーションの主要な分類であり、既存のセッション識別子を無効化せずにユーザーを認証する弱点を定義しています。MITRE分類でのプロファイル：
- 弱点タイプ： セッションクレデンシャルカテゴリ内の基本弱点
- 主な影響： 権限昇格または被害者のなりすまし；セッション存続期間中の完全なアカウント乗っ取り
- 悪用可能性： 中程度 — ログイン前に既知のセッションIDを被害者に配布する必要あり
- プラットフォーム範囲： 言語非依存；Webスタックやフレームワークに関係なく適用
- CWE Top 25ステータス： 2019年にTop 25入り；2023年版でもアクティブな追跡対象
これらの特性により、CWE-384は脆弱性スキャナーやアセスメントフレームワークで一貫したシグナルとなり、セッションライフサイクル管理を対象としたテストケースに直接マッピングされます。
OWASP Top 10およびテスト基準
CWE-384は A07:2025 — 認証制御の失敗（OWASP Top 10）にマッピングされます。この分類は重要な意味を持ちます。セッションフィクセーションはクッキー設定ミスではなく、認証制御の失敗として扱われます。この違いにより、ログインフローのレビューや認証強化作業の対象となり、単なるクッキー設定監査に留まりません。
| 参照 | システム | 目的 |
| MITRE CWE | 正式な弱点追跡；SAST/DASTツールやCVE記録で使用 | |
| OWASP Top 10 | リスク優先度シグナル；認証制御レビューの範囲を規定 | |
| OWASP WSTG | 権威あるブラックボックステスト手順と合否基準 | |
| OWASP CheatSheets | 再生成、クッキースコープ、厳格モードの開発者向け防止リファレンス |
これら4つの参照により、セッションフィクセーションへの対応に必要な用語、テストケース、対策ガイダンスが得られます。分類の文脈が明確になったところで、実際に脆弱性が悪用された場合に何が起こるかを見ていきます。
セッションフィクセーションの影響とリスク
セッションフィクセーションは、侵害されたセッションの存続期間中、完全なアカウント乗っ取りを可能にします。攻撃者が認証済みセッションIDを保持すると、被害者が持つ全ての権限で操作できます。機密データの閲覧、取引の開始、アカウント設定の変更、被害者が管理者権限を持つ場合は権限昇格も可能です。
OWASP分類と深刻度
CWE-384は OWASP A07に該当します。A07:2025カテゴリは平均加重悪用可能性スコア7.69で、 7,147件のCVEがテスト済みアプリケーションでマッピングされています。A07カテゴリにマッピングされたCVE総数は2021年版から2025年版で増加しており、 攻撃対象領域の拡大を反映しています。
CVSSスコア範囲
確認されたセッションフィクセーションCVEは 中程度からクリティカルまで幅広いです。最も高評価のケースは、フィクセーションにより広く利用されている認証プラグインやフレームワークで未認証アカウント乗っ取りが可能となるシナリオです。実務者として重要な点は、セッションフィクセーションCVEはNIST NVDとベンダーCNA間でスコアの不一致が頻繁に見られることです。例えばCVE-2019-17563（Apache Tomcat）はNISTでCRITICAL評価ですが、Apacheは「実用的な悪用にはウィンドウが狭すぎる」として「Low」と評価しています。
複合リスク要因
セッションフィクセーションは単独リスクであることは稀です。CVE-2024-56529（Mailcow）は、被害者のブラウザでHSTSが無効な場合に攻撃が成立することを示しています。Microsoft Researchの論文（IEEE S&P 2015）は、クッキーインジェクションが実際のWebサイトで標準的なセッション再生成防御を回避できることを示しました。多層防御が同時に失敗すると、セッションフィクセーション脆弱性は急速に深刻化します。脆弱な対象はWebアプリケーションだけに留まりません。
攻撃者によるセッションフィクセーションの悪用方法
攻撃者は、標的型フィッシングから機会的なセッションポイズニングまで、さまざまなシナリオでセッションフィクセーションを悪用します。
フィッシングベースのURLインジェクション
攻撃者は既知のセッションIDを含むURLを作成し、 フィッシングや ソーシャルエンジニアリングで配布します。URLは実際のアプリケーションドメインを指しているため正規に見えます。被害者がリンクをクリックし、通常通りログインすると、攻撃者が制御するセッションで認証されます。これはURLベースのセッションID伝送で最も一般的なシナリオです。
公共端末の悪用
MITRE CWE-384は典型的なシナリオを文書化しています。攻撃者が公共端末でセッションを作成し、セッション識別子を記録し、ブラウザをログインページにリセットして次のユーザーが認証するのを待ちます。アプリケーションは既存のセッションIDを使い続け、攻撃者に「セッション存続期間中、被害者アカウントへのほぼ無制限のアクセス」を与えます。
非標的型セッションポイズニング
CVE-2022-30769（ZoneMinder）は、攻撃者が「次にログインするユーザーのためにセッションクッキーをポイズニングできる」攻撃を実証しました。特定の個人を標的にする必要はありません。ポイズニングされたセッションは次に認証したユーザーに引き継がれます。監視プラットフォームのような共有アクセス環境では特に危険です。
レースコンディションの悪用
CVE-2013-2067（Apache Tomcat）は、FORM認証のレースコンディションを明らかにしました。被害者がログインフォームを入力している間に、攻撃者が認証済みリソースへのリクエストを繰り返し送信することで、被害者の認証情報で実行されるリクエストを注入できました。Apacheはこれを「重要」な深刻度と評価しました。
クロスサブドメイン攻撃
トップレベルドメインを共有するマルチアプリケーション構成では、攻撃者は低セキュリティアプリケーションを悪用し、親ドメインにスコープされたセッションクッキーを固定します。そのドメイン配下の他の全アプリケーションが固定されたセッションIDを受け入れます。これは複数の内部ツールを共有ドメインで運用するエンタープライズ環境でよく見られます。影響範囲を知ることで、脆弱性の調査優先度を決められます。
セッションフィクセーションの影響範囲
セッションフィクセーションは、ユーザーセッションを識別子で管理し、認証時にそれを再生成しない全てのアプリケーションに影響します。CVE記録やMITRE文書は、構造的に高リスクなカテゴリをいくつか指摘しています。
- URLベースのセッション識別子を使うWebアプリケーションは最も直接的なリスクに直面します。URLベースのセッション伝送は、攻撃者が細工したリンクで制御下のセッションIDを配布でき、追加の脆弱性を必要としません。
- CMSおよび認証プラグインエコシステムは繰り返し影響を受けています。CVE-2024-13279（Drupal TFA、 CISA参照）、CVE-2010-1434（Joomla!）、CVE-2012-5391（MediaWiki）、CVE-2019-8116（Magento）は、CMSプラットフォーム上の認証モジュールがセッション再生成を強制しない場合、重大なセッションフィクセーションリスクを導入することを示しています。
- J2EE/Java EEアプリケーションは、最も広範なCVE記録があります。Apache Tomcatだけでも2013年から2025年にかけてCVEが存在し、CVE-2013-2067、CVE-2014-0033、CVE-2015-5346、CVE-2019-17563、CVE-2025-55668などが含まれます。
- マルチアプリケーション共有ドメイン構成は設計上脆弱です。テナントサブドメインを持つSaaSプラットフォームや、トップレベルドメインを共有するエンタープライズアプリケーション群は、MITREが直接文書化しているクロスサブドメインフィクセーションリスクに直面します。
- ICS/SCADAプラットフォームは新たなリスク領域です。CVE-2025-70973（ScadaBR 1.12.4、2026年3月公開）は、産業制御システムプラットフォームでのセッションフィクセーションを示しており、CWE-384のICSカテゴリマッピング（CWE-1364、CWE-1366）と一致します。
- エンタープライズワークフロープラットフォームも文書化されたリスクを持ちます。CVE-2022-38369（Apache IoTDB）、CVE-2022-38054（Apache Airflow）は、ワークフロー自動化ツールも例外ではないことを示しています。影響範囲の広さから、実際の事例が脆弱性の現れ方を理解する上で有用です。
セッションフィクセーションの実例
セッションフィクセーションは、エンタープライズJavaフレームワークから産業制御プラットフォームまで、幅広い本番システムで確認されています。以下の例は、同じ根本的な欠陥が環境によってどのように異なる形で現れるかを示しています。
Apache Tomcat FORM認証レースコンディション（CVE-2013-2067）
これはTomcatのセッションフィクセーションCVEで最も影響が大きく、 Apacheで「重要」と評価されています。Tomcat 6.0.21～6.0.36および7.0.0～7.0.32に影響し、FORM認証のレースコンディションを悪用します。攻撃者は被害者がログインフォームを入力している間に認証済みリソースへのリクエストを繰り返し送信し、被害者の認証情報で実行されるリクエストを注入できます。皮肉なことに、認証時のセッションID変更オプション自体がTomcat 6.0.21で追加されていました。このCVEはTomcat自身の フィクセーション対策のバグでした。
SymfonyフレームワークCSRFトークンバイパス（CVE-2022-24895）
Symfony 2.0.0～6.2.5は 高深刻度脆弱性の影響を受けました。フレームワークはログイン時にセッションIDを再生成しますが、CSRFトークンなど他のセッション属性は維持されていました。この部分的な再生成により、同一サイト攻撃者がセッションフィクセーションの変種でCSRF防御を回避できました。教訓は明確で、セッションIDだけでなく、完全なセッションの無効化と再発行が必要です。
ScadaBR産業制御システム（CVE-2025-70973）
2026年3月公開のこの脆弱性は、ScadaBR 1.12.4で典型的なセッションフィクセーションパターンに従います。アプリケーションは未認証ユーザーにJSESSIONIDセッションクッキーを割り当て、認証後もセッション識別子を再生成しません。ログイン前に作成されたセッションが、被害者のログイン後に認証済みとなります。このCVEは、ICS/SCADA環境でのセッションフィクセーションリスクを示す点で注目されます。
ZoneMinder非標的型セッションポイズニング（CVE-2022-30769）
ZoneMinder 1.36.12以前は、攻撃者が次に認証するユーザーに引き継がれるセッションクッキーをポイズニングできました。特定の被害者を狙う必要がなく、複数のオペレーターが同じプラットフォームにアクセスする監視環境では特に危険です。
PHPセッションアダプション（CVE-2011-4718）
PHPのセッションモジュールは「アダプティブ」で、外部ソースからのセッションIDを受け入れていました。 PHP RFCは「session_regenerate_id()の使用だけでは、session.use_strict_modeを有効にしない限りセッションアダプション/フィクセーションは防げない」と述べています。PHP 5.5.2でsession.use_strict_modeが 修正として導入されましたが、strict mode有効でもカスタムセーブハンドラでは脆弱な場合があります。これらの事例の歴史的記録は、この脆弱性クラスが長期間存続していることを示しています。
セッションフィクセーションのタイムラインと歴史
セッションフィクセーションは2002年から正式に文書化されており、CVE記録は新旧コードベースで依然としてアクティブであることを示しています。以下のタイムラインは主要な公開イベントとフレームワークレベルの対応を示します。
| 年 | イベント |
| 2002年12月 | Mitja Kolšek（ACROS Security）が「Session Fixation Vulnerability in Web-based Applications」を発表し、セッションフィクセーションをセッション識別子に対する第4の攻撃クラスとして正式命名 |
| 2006年 | CVE-2006-1228（Drupal 4.5.x/4.6.x）：URLベースのセッションIDフィクセーション |
| 2006年7月 | MITREがCWE-384をCommon Weakness Enumeration（ドラフト3）に追加 |
| 2008年2月 | Oracle/BEA WebLogic ServerアドバイザリBEA08-196.00：セッションフィクセーションによる権限昇格 |
| 2009年 | CVE-2009-1580（SquirrelMail）；Black Hat USAがBitTorrentトラッカーコミュニティでCWE-384を文書化 |
| 2010年 | CVE-2010-1434（Joomla! 1.5.0～1.5.15）：CVSS 7.5 HIGH |
| 2011年12月 | CVE-2011-4718（PHPセッションアダプション）：PHP 5.0.0～5.5.1に影響 |
| 2013年5月 | CVE-2013-2067（Apache Tomcat 6.x, 7.x）：FORM認証レースコンディション、Apache「重要」 |
| 2015年 | Microsoft Research（IEEE S&P）が広く採用された再生成防御を回避するクッキーインジェクションを文書化 |
| 2019年 | CWE-384が Top 25入り |
| 2019年12月 | CVE-2019-17563（Apache Tomcat）：NIST 9.8 CRITICAL、Apache「Low」 |
| 2022年 | CVE-2022-24895（Symfony）：部分的再生成バイパス |
| 2025年1月 | CVE-2024-56529（Mailcow）：HSTS無効時のセッションフィクセーション |
| 2025年8月 | CVE-2025-55668（Apache Tomcat 9.x/10.x/11.x）：CVSS 6.5 MODERATE |
| 2026年3月 | CVE-2025-70973（ScadaBR 1.12.4）、CVE-2026-25101（Bludit）：新たなCVEが脆弱性クラスの継続を確認 |
このタイムラインは20年以上にわたり続いており、減速の兆しはありません。セッションフィクセーションは過去の脆弱性ではなく、エンタープライズフレームワークからICSプラットフォームまで新旧コードベースで現れ続けています。自社アプリケーションをレビューする方法を知っていれば、次のステップに進めます。
セッションフィクセーションの検出方法
セッションフィクセーションは比較的確認が容易な脆弱性です。基本的なテストは、ログイン前にセッション識別子を取得し、認証後に値を比較するだけです。以下のアプローチは、 手動検証、クッキー属性の確認、自動スキャン、WAF層での識別をカバーします。
手動ペネトレーションテスト（OWASP WSTG-SESS-03）
権威あるテスト手順は OWASP WSTGに記載されています。ブラックボックステストは以下の通りです。
- 認証前のセッションIDを取得。 アプリケーションにアクセスし、セッションクッキー値
(例：JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1)を記録します。 - 取得したセッションIDを提示して認証。 元のセッションクッキーを付与したまま有効な認証情報を送信します。
- セッションID値を比較。 認証後もサーバーが同じセッションIDを返す場合、アプリケーションは脆弱です。
HSTSが完全に導入されていないアプリケーションでは、WSTG-SESS-03は第2の戦略を記載しています。ログイン後に新たに発行されていない全てのクッキーを別のマシンから被害者のブラウザに強制投入し、それらのクッキーで認証後のセッションアクセスが可能か確認します。
クッキー属性の確認
セッションクッキーのハードニング指標を確認します。__Host-プレフィックスはネットワークベースのセッションフィクセーションに対する整合性を提供します。__Secure-プレフィックスは部分的なハードニングを示します。 WSTG-SESS-03を実行し、HttpOnly、Secure、SameSite属性が正しく設定されているか検証します。
DASTスキャン
OWASP ZAPは、セッション管理サポートを含むアクティブ・パッシブ両モードのスキャンを提供し、クッキーやトークンなどのメカニズムを扱います。ZAPのセッション・認証強制分析は、 認証不備やセッションフィクセーションバグの発見に役立ちます。Burp Suite Professionalはセッション管理テストワークフローをカバーし、セッション管理テストに適用できる動的Web脆弱性スキャナーとして機能します。
WAFベースの識別
OWASPシートは、ModSecurityとOWASP Core Rule Setの組み合わせがセッションフィクセーション攻撃への対策を提供するとしています。この WAF層アプローチは、ソースコードが利用できない、修正できない、またはアプリケーションレベルの完全な修正に大規模な再設計が必要な場合に推奨されます。効果的なレビューは直接的な防止につながり、必要な制御は明確に定義されています。
セッションフィクセーションの防止方法
防止の中心は1つの絶対要件です。アプリケーションは認証イベントごとに新しいセッションIDを発行し、サーバー自身が生成していないセッション識別子は拒否しなければなりません。以下の制御は、アプリケーション層、フレームワークレベル、クッキー設定、ネットワークアーキテクチャでこの要件に対応します。
アプリケーション層の制御
- 認証後にセッションIDを再生成。 これが最も重要な制御です。OWASP WSTG-SESS-03は「アプリケーションはユーザー認証前に既存のセッションIDを必ず無効化し、認証成功時に新たなセッションIDを提供すべき」と明記しています。再生成はログイン、パスワード変更、権限変更、ロール遷移など全ての権限レベル変更時に必須です。
- 厳格なセッション管理を使用。 アプリケーションをサーバー生成のセッションIDのみ受け入れるよう構成します。クライアントから送信された任意のセッションID値は拒否します。PHPはこの目的でバージョン5.5.2からsession.use_strict_modeを導入しました。
- セッションを完全に無効化。 CVE-2022-24895（Symfony）は、部分的なセッション再生成が不十分であることを証明しました。セッションIDのみ再生成し、CSRFトークンなど他のセッション属性を維持すると残存脆弱性が生じます。完全なセッション無効化と再発行が必要です。
フレームワーク固有の実装
| フレームワーク | 既存セッションの無効化 | 新規セッションの作成 |
| J2EE | HttpSession.invalidate() | request.getSession(true) |
| ASP.NET | Session.Abandon() | Response.Cookies.Add(new HttpCookie(...)) |
| PHP | session_start() | session_regenerate_id(true) |
Spring Securityは、ユーザーのログイン時に新しいセッションを作成またはセッションIDを変更することで、セッションフィクセーションから自動的に保護します。4つの構成可能な戦略があり、changeSessionId()（推奨）、migrateSession(), newSession(), none()（非推奨）があります。
クッキーセキュリティ設定
NIST SP 800-63B要件に従います：
Secureフラグ：必須（クッキーはHTTPSのみで送信）DomainおよびPath：最小限の範囲に制限することHttpOnlyフラグ：推奨（JavaScriptからのアクセス防止）SameSite=LaxまたはStrict: 推奨（NIST SP 800-63B v4ドラフト）__Host-プレフィックスとPath=/:推奨（NIST SP 800-63B v4ドラフト）
これらのフラグを組み合わせて適用することで、最も一般的なネットワークベースおよびクロスサイトフィクセーション配布シナリオを防ぎ、 クッキーインジェクションを試みる攻撃者に対する難易度を大幅に高めます。
アーキテクチャレベルの制御
異なるセキュリティレベルのアプリケーションを同一ドメインで混在させないでください。サブドメインを含む完全なHSTSを実装し、ネットワークベースのフィクセーションを防ぎます。アプリケーションレベルの変更がすぐにできない場合は、ModSecurityとOWASP Core Rule SetをWAF層で導入してください。防止とレビューは適切なツールによって最も効果を発揮します。
検出と防止のためのツール
セッションフィクセーションの特定と阻止には、実際の攻撃条件をシミュレートする動的スキャナー、コードレベルで安全なデフォルトを強制するフレームワークネイティブの保護、認証済みセッションに到達したフィクセーションベースの侵入を検知する振る舞い分析の3層のツールが必要です。以下のツールはこれら全てをカバーします。
DASTおよびペネトレーションテストツール
- OWASP ZAPは無料のオープンソース動的アプリケーションセキュリティテストツールです。 公式ドキュメントによれば、ZAPはアクティブ・パッシブ両モードでセッション管理の欠陥（セッションフィクセーション含む）を検出します。
- Burp Suite Professionalは セッションテストワークフローと、セッショントークン取り扱い脆弱性を特定するスキャナールールを提供します。手動テスト機能により、WSTG-SESS-03手順をリクエスト/レスポンスの可視化付きで実施できます。
- ModSecurityとOWASP Core Rule Setは、セッションフィクセーションに対するWAF層の対策を提供し、セキュリティクッキー属性の識別・強制、スティッキーセッショントラッキング、権限変更時のセッションID更新を実現します。
フレームワークのセキュリティ機能
Spring Securityの組み込みセッションフィクセーション対策、PHPのsession.use_strict_modeおよびsession_regenerate_id()、ASP.NETのSession.Abandon()は、いずれも言語ネイティブの防止策です。これらの機能がデフォルト設定に頼らず、正しく有効化・構成されていることを確認してください。
関連する脆弱性
セッションフィクセーションは単独で機能するものではありません。CWE-384と配信手法、悪用条件、リスク増幅要因を共有する密接な関連弱点が複数存在します。これらをグループで理解することで、セッションフィクセーション単独よりも強力な対策範囲が得られます。
- クロスサイトスクリプティング（CWE-79）はセッションフィクセーションの配信手段となります。リフレクト型XSSは、被害者のブラウザで制御下のセッションクッキーを設定するJavaScriptを注入できます。XSS対策は主要なフィクセーション配信経路の1つを遮断します。
- クロスサイトリクエストフォージェリ（CWE-352）はセッションフィクセーションと混同されがちですが、仕組みが異なります。CSRFはブラウザの自動クッキー送信を悪用し、認証済みセッションからリクエストを偽造します。攻撃者がセッションIDを知る・制御する必要はありません。CWE-352は 2023年CWE Top 25で9位です。
- 不適切な認証（CWE-287）はセッションフィクセーションと密接に関連し、同じOWASP A07認証制御失敗カテゴリに位置します。CWE-287は全ての認証不備をカバーし、2023年CWE Top 25で13位、CISA Known Exploited Vulnerabilitiesカタログに10件登録されています。
- 不十分なセッション有効期限（CWE-613）](https://www.sentinelone.com/cybersecurity-101/cybersecurity/enterprise-application-security/)は、固定されたセッションIDの有効期間を延長することでセッションフィクセーションリスクを増幅します。長いセッションタイムアウトは、攻撃者が固定セッションを悪用する時間を増やします。
- 予測可能な数値生成（CWE-340）は、MITREの分類でCanFollow関係を通じてセッションフィクセーションに先行することがあります。予測可能なセッション識別子は、攻撃者が有効なセッションID値を推測しやすくします。セッションフィクセーション単独の対策ではリスク全体をカバーできないことが多く、これら関連弱点も同時にレビューすることで、フィクセーションが初期侵入に利用するギャップを埋められます。
関連CVE
CVE ID | 説明 | 深刻度 | 影響製品 | 年 |
| ログイン後にセッション識別子が再生成されない；攻撃者が認証前に被害者のセッションIDを設定し、認証後のセッションを乗っ取る | 保留中 | OpenSolution: Quick.Cart | 2026 | |
| リモート認証でSSO変数を使用時にセッションフィクセーションが発生；攻撃者が同一マシン上で他ユーザーが開いたセッションを盗むことが可能 | 保留中 | GLPI (≥ 0.71 < 10.0.23; ≥ 11.0.0-alpha < 11.0.5) | 2026 | |
| セッションフィクセーション（CWE-384）により、攻撃者がユーザーのセッションを乗っ取り、被害者になりすまして不正取引を実行可能 | 中 (6.5) | HCL Technologies: Aftermarket DPC (Aftermarket Cloud 1.0.0) | 2025 | |
| ManageEngine ADSelfService Plusのセッション管理不備（CWE-287）；低権限認証済みユーザーが他ユーザーアカウントを乗っ取る | 高 (9.3) | Zohocorp ManageEngine ADSelfService Plus (≤ build 6510) | 2025 | |
| GoFiberセッションミドルウェアのセッションフィクセーション（CWE-384）；ユーザー指定のsession_id値を受け入れ、攻撃者が認証済みセッションキーを制御可能 | クリティカル (9.8) | GoFiber: Fiber (< 2.52.5) | 2024 | |
| 非推奨のVMware Enhanced Authentication Plug-inにおけるセッションハイジャック（CWE-384）；ローカル非特権攻撃者が特権ドメインユーザーの認証済みEAPセッションを乗っ取る | 高 (7.8) | VMware: Enhanced Authentication Plug-in (非推奨) | 2024 | |
| 非推奨のVMware EAPにおける認証リレーとセッションハイジャック；悪意のあるアクターがドメインユーザーに任意のActive Directory SPN用のKerberosサービスチケットをリレーさせる | クリティカル (9.6) | VMware: Enhanced Authentication Plug-in (非推奨) | 2024 | |
| Apache SupersetでデフォルトのSECRET_KEYがセッションクッキー署名に使用されている；デフォルト値を知る攻撃者が有効なセッションクッキーを偽造し、管理者を含む任意ユーザーとして認証可能；CISA KEV | クリティカル (9.8) | Apache Superset (≤ 2.0.1) | 2023 | |
| SessionListener#sessionDestroyed()から例外がスローされた場合、セッションIDマネージャでセッションIDが有効なまま残る（CWE-613）；共有PCで前ユーザーのセッションにログアウト後もアクセス可能 | 低 (3.5) | Eclipse Jetty (< 9.4.41, < 10.0.3, < 11.0.3) | 2021 | |
| デフォルトのシークレットキーで署名されたセッショントークンが異なるAirflowデプロイ間で受け入れられる；1つのインスタンスで認証済みのユーザーが他のインスタンスに再認証なしでアクセス可能 | 高 (8.8) | Apache Airflow Webserver (< 1.10.14) | 2020 |
まとめ
セッションフィクセーションは、アプリケーションが認証後にセッションIDを再生成しないという、単一でよく知られた不備を悪用します。CWE-384として正式分類され、OWASP Top 10 2025 A07にマッピングされており、CMSプラットフォーム、Javaフレームワーク、PHPアプリケーション、ICS/SCADAシステムにわたり発生し続けています。
リスク低減には、権限変更ごとのセッションIDローテーション、厳格なセッション受け入れの強制、クッキースコープのハードニング、認証後のアクティビティレビューによる悪用検知が有効です。
よくある質問
セッションフィクセーションは、アプリケーションがログイン前後で同じセッションIDを保持する場合に発生します。攻撃者はまず被害者に既知のセッションIDを使わせ、その後被害者が認証するのを待ちます。
アプリケーションが新しいIDを発行しない場合、攻撃者はそのまま認証済みセッションを利用できます。主な防御策はシンプルで、古いセッションを無効化し、ログインや権限変更後に新しいセッションを作成することです。
はい。CWE-384はOWASP Top 10 2025 A07: Authentication Failuresに含まれています。防御者としては、ラベルよりも優先度のシグナルとして重要です。セッションフィクセーションは単なるCookie設定ミスではなく、認証失敗として扱われます。
ログインフローのレビュー、セッション管理テスト、認証強化作業に含めるべきです。
はい。攻撃者が被害者に選択したセッションIDを使わせる手段があれば、リモート配信は一般的です。これは細工されたURL、ブラウザ側スクリプト、悪意あるレスポンス、同一親ドメイン上の脆弱なアプリケーションなどで発生します。
物理的アクセスが必要なのは、共有端末や公共端末などのシナリオのみです。
最もリスクの高いアプリケーションは、ユーザーが提供したセッションIDを受け入れるものや、認証後にセッションIDをローテーションしないものです。この記事で挙げられている一般的な例としては、URLベースのセッションスキーム、CMS認証モジュール、Javaアプリケーションスタック、共有ドメイン環境、ワークフロープラットフォーム、ICS/SCADAウェブインターフェースなどがあります。
共通しているのは、単一の言語や業界ではなく、セッションライフサイクル管理の脆弱さです。
ログイン後もセッションが変更されずに維持されるかどうかをテストします。簡単な方法は、認証前のセッションIDを取得し、それで認証して値を比較することです。
同じIDが有効なままであれば、脆弱性が存在します。スキャンツールも役立ちますが、部分的な再生成やサブドメイン間のCookie挙動などの特殊ケースには手動テストが必要です。
1つのセッションが2人のユーザーに所有されているような挙動を探してください。実際の警告サインとしては、同じセッションが異なるIPアドレスから現れる、急なデバイスや場所の変化、ログイン直後にアクセスパターンが変化するなどがあります。
セッション識別子をURLで認証エンドポイントに送信するリクエストも、通常の閲覧ではなくフィクセーションの試みを示す場合があります。
深刻度は侵害されたアカウントの権限によります。価値の低い環境では中程度と評価される場合もありますが、高価値システムでは同じ脆弱性でアカウントの完全乗っ取りや管理者権限の悪用が可能です。
記事内のCVE例は4.6から9.8まであり、セッションフィクセーションが本質的に軽微ではないことを示しています。影響は権限、露出、周辺コントロールによって決まります。
標的アカウントの完全な侵害につながる可能性があり、被害者が管理者の場合はさらに広範な侵害となる場合があります。攻撃者が昇格した権限を得ると、設定変更や機密データへのアクセス、環境全体に影響する操作が可能です。
脆弱性自体はセッションを標的としますが、ビジネスへの影響は単一のログインを超える場合があります。
最も単純な形態は、ツールが認証前後のセッションIDを比較できるため比較的容易に発見できます。難しいケースは、部分的な再生成やサブドメイン間で継承されるCookie、トランスポートやブラウザ挙動に依存する条件などです。
実際には、スキャンによる網羅性は有用ですが、実際の悪用可能性を確認するには集中的な手動テストが依然として重要です。
認証付きWebアプリケーションを運用するすべての業界が対象となり、特にユーザーが機密データや取引を扱う場合はリスクが高まります。この記事では、eコマース、エンタープライズプラットフォーム、共有ドメイン環境、医療系の規制システム、ICS/SCADA展開などを挙げています。
プラグイン、レガシーなセッション管理、複数アプリケーションが親ドメインを共有している場合、リスクが高まります。
