セッションフィクセーションとは？
セッションフィクセーションは、セッション識別子の管理不備を悪用して攻撃者が正規ユーザーのセッションを乗っ取ることを可能にするWebアプリケーションの脆弱性です。根本的な問題は単純で、ユーザーが認証した際にアプリケーションが新しいセッションIDを割り当てないことにあります。つまり、攻撃者が認証前のセッション識別子を知っている、または制御している場合、その識別子を使って認証済みセッションへアクセスし、正規ユーザーになりすますことができます。
MITRE CWEはこの弱点を正式に次のように定義しています。「ユーザーを認証する、または新しいユーザーセッションを確立する際に、既存のセッション識別子を無効化しない場合、攻撃者は認証済みセッションを盗む機会を得る。」その結果、被害者が何も気付かないまま、ほぼ完全なアカウント乗っ取りが発生します。
セッションフィクセーションはセッションハイジャックとは異なりますが、混同されることもあります。OWASPはこの違いを明確に示しています。セッションフィクセーションは被害者がログインする前に始まり、 セッションハイジャックは既に認証済みのアクティブなセッションが存在した後に発生します。フィクセーション攻撃では、攻撃者はセッションIDを自ら設定することで既に知っています。ハイジャック攻撃では、攻撃者はアクティブなセッションからセッションIDを取得または予測する必要があります。
| 属性 | セッションフィクセーション | セッションハイジャック |
| 攻撃タイミング | 被害者が認証する前 | 被害者が認証した後 |
| セッションIDの知識 | 攻撃者が事前にIDを設定または知っている | 攻撃者がIDを取得または予測する必要がある |
| 主な対策 | ログイン時のセッションID再生成 | トークン暗号化、安全な送信 |
この違いはセキュリティ制御にとって重要です。アプリケーションがログイン後にセッションIDを再生成すれば、フィクセーション攻撃を防げます。トークンを転送時に暗号化するだけではハイジャックには対応できますが、フィクセーションには無防備です。攻撃の仕組みを理解すれば、この違いがなぜ重要なのかが分かります。
セッションフィクセーションの仕組み
セッションフィクセーションは、 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は「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がパターン化されていたり、乱数性が弱い場合、攻撃者はサーバーから取得せずとも有効な値を予測できます。
許容的なCookieドメインスコープ
Domainクッキー属性をトップレベルドメイン、例えばDomain=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 高 |
| 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 中程度 |
| 2026年3月 | CVE-2025-70973（ScadaBR 1.12.4）およびCVE-2026-25101（Bludit）：新たなCVEが脆弱性クラスの継続的存在を確認 |
このタイムラインは20年以上にわたり、減速の兆しはありません。セッションフィクセーションは過去の脆弱性ではなく、エンタープライズフレームワークからICSプラットフォームまで、新旧コードベースで引き続き発生しています。自社アプリケーションをレビューする方法を知っていれば、次のステップに進めます。
セッションフィクセーションの検出方法
セッションフィクセーションは比較的簡単に確認できる脆弱性の1つです。基本的なテストは、ログイン前にセッション識別子を取得し、認証後に値を比較するだけです。以下のアプローチは、 手動検証、クッキー属性の確認、自動スキャン、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展開などを挙げています。
プラグイン、レガシーなセッション管理、複数アプリケーションで親ドメインを共有している場合、リスクが高まります。
