概要
セッションの固定化(英:Session Fixation)は、攻撃者の用意したセッションIDを正規利用者に強制使用させる攻撃手法です。「セッション固定攻撃」や「セッションフィクセーション」とも呼ばれ、 利用者がログインなどでセッションを確立した後、攻撃者が利用者と同じセッションIDを使用することで利用者になりすまして不正な操作を行います。
また、セッションの固定化が可能な場合はセッションハイジャックを引き起こす一つの原因となります。
セッションハイジャックについては別の記事で詳細に説明しています。
関連ゼイジャッキー
セッションフィクセーション
お手製のCookieをみんなに配る心優しいゼイジャッキー。 しかし、それは作られた仮面に過ぎなかった……。
受け取ったCookieをずっと持ったままログインすると、ゼイジャッキーがユーザになりすまして権限を悪用してしまう。
なりすまされたユーザは登録情報を変更されてしまったり、ユーザの権限で不正に操作されてしまったりという被害を受ける。
ゼイジャッキーとは？
セッションとは？
利用者がWebサイトにアクセスしてからブラウザを閉じるなどして通信が終了するまでの一貫性を持った通信のことをセッションといいます。
セッションが存在する間は通信の内容や「状態(ステート)」が保持されるため、ある通信の操作を次の通信に反映させることが可能です。
ログイン機能をもつWebアプリでは、ログイン後に利用者ごとの機能を提供するために状態を保持して、どの利用者の操作であるか識別し続ける必要があります。 そして、サーバ側で利用者を判別するためには、セッションIDと呼ばれる識別子を利用します。
セッションについて、以下の記事で詳細に説明しています。
セッションの固定化の仕組み
ログイン前後でセッションIDが変更されない場合、セッションの固定化に対して脆弱になります。
以下の図は、ログイン処理でセッションの固定化の影響を受ける脆弱なサイトの例です。
1. 攻撃者がセッションIDを取得する
攻撃者は利用者にセッションIDを強制するために、正規サイトからセッションIDを取得する必要があります。
ここで取得するセッションIDは正規サイトにアクセスした際に生成されるセッションIDです。
セッションの固定化ではログイン前後でセッションIDが変わらないことが前提のため、攻撃者はログインする必要はありません。
2. 利用者にセッションIDを強制する
攻撃者は取得したセッションIDを何らかの方法によって利用者に送り付け、利用者にセッションIDを強制させます。
強制する方法については次章で例を紹介します。
3. 利用者がログインする
利用者が攻撃者に強制されたセッションIDを使って正規サイトにログインします。
利用者がログインに成功すると、正規サイトではセッションIDと利用者の紐づけを行い記憶します。
4. 利用者になりすましてアクセスする
正規サイトでは、利用者との紐づけが行われたセッションIDでアクセスすれば、利用者になりすますことができます。
攻撃者は利用者に強制したセッションIDを既に知っているため、利用者になりすまして不正な操作を行うことができます。 
攻撃成立までの流れ
これらの手順をまとめると次の図のような流れで攻撃は成立します。
代表的な攻撃手法
攻撃者が利用者にセッションIDを強制する方法として3つ挙げられます。
- URLにセッションIDを埋め込む方法
- スクリプトを使用し、セッションIDを強制する方法(クロスサイトスクリプティング脆弱性)
- レスポンスヘッダを追加してCookieを強制する方法
各項目について例を用いて解説します。
なお、URLにセッションIDを埋め込む方法を除き、以下の例ではセッションIDがCookieで管理されていることを前提にしています。
URLにセッションIDを埋め込む方法
この方法を行う場合、正規サイトの仕様でセッションIDがURLに含まれることが必要です。
|
http://example.com/login?sessionid=ABC |
攻撃者は自身が取得したセッションIDを含めたリンクをSNSやメールを用いて利用者に送信します。
利用者がリンクをクリックした後にそのまま正規サイトにログインしてしまうと、攻撃者によって不正な操作が行われます。
SNSやメールに記載されるリンクのドメインは、正規サイトのドメインのため気づきにくい可能性があります。
また、正規サイトでURL Rewriting機能が有効になっている場合は、セッションIDをCookieで管理していてもURLクエリパラメータを利用して受理させることが可能です。
スクリプトを使用し、セッションIDを強制する方法(クロスサイトスクリプティング脆弱性)
正規サイトにクロスサイトスクリプティング脆弱性が存在する場合、攻撃者がスクリプトを使用して任意のセッションIDを強制することが可能になります。
以下のようなスクリプトが利用者のブラウザ上で実行された後に、利用者が正規サイトにログインしてしまうと、攻撃者によって不正な操作が行われます。
|
<script>document.cookie="sessionid=ABC"; </script> |
このスクリプトが実行されると利用者のブラウザ上でセッションIDが設定されます。
正規サイトは既にセッションIDを持っていると認識して新しいセッションIDを発行しません。
クロスサイトスクリプティングについて、以下の記事で詳細に説明しています。
レスポンスヘッダを追加してCookieを強制する方法
HTTPヘッダインジェクション脆弱性が存在するWebサイトにおいて、攻撃者がSet-Cookieヘッダを挿入することで利用者にCookieを強制し、利用者は攻撃者によって任意のセッションIDを強制される可能性があります。
HTTPヘッダインジェクションについて、以下の記事で詳細に説明しています。
JVN iPediaに登録された本脆弱性の件数
直近10年間でセッションの固定化に関する脆弱性（CWE-384）が存在する可能性があるとして報告され、JVNに登録された件数です。
| 年代 | 件数 |
| 2014 | 3件 |
| 2015 | 4件 |
| 2016 | 11件 |
| 2017 | 18件 |
| 2018 | 47件 |
| 2019 | 41件 |
| 2020 | 35件 |
| 2021 | 19件 |
| 2022 | 39件 |
| 2023 | 34件 |
※上記の表はMyJVN APIを利用してCWE識別子を基に統計した件数です。
JVNDBRSS - JVN iPediaにて公開している脆弱性対策情報の概要
対策方法
セッションの固定化は外部からのセッションIDを強制できてしまう設定・設計になっていることが問題です。
以下では具体的な対策方法について紹介します。
1. ログイン成功後に、新しくセッションを開始する
セッションの固定化が可能になる条件として、ログイン前とログイン後でセッションIDが同じである必要があります。
ログイン成功時にサーバ側でセッションIDを新しく設定しなおすことで、攻撃者が知っているセッションIDとは異なるセッションIDに変わるためセッションの固定化を防ぐことができます。
また、新しくセッションIDを生成したときには既存のセッションIDは無効にすべきです。
無効にすることで攻撃者が事前に取得していたセッションIDではアクセス不可能になります。
2. ログイン成功後に既存のセッションIDとは別にランダムな値を生成し、ページの遷移ごとにその値を確認する
フレームワーク等によってセッションIDの再発行が行えず、対策1が実施できない場合は、本対策を実施することを推奨します。
ログイン成功時にフレームワーク等が発行するセッションIDとは別にサーバ側でランダムな値を生成します。このランダムな値はフレークワーム等が発行するセッションに紐づけて管理します。また、生成したランダムな値はCookieに格納してクライアント側に返却します。
ログイン後の各リクエストにおいては、生成したランダムな値がCookieとして送られてきているか・フレームワーク等が発行するセッションIDと正しく紐づいている値であるかを検証することで正しい利用者であるか判断します。
攻撃者はログイン成功時に発行されるランダムな値を知ることができないため、フレームワーク等が発行するセッションIDを固定化できたとしてもセッションハイジャックを行うことができなくなります。
まとめ
セッションの固定化の脆弱性が存在していると攻撃者によって任意のセッションIDを強制されます。
利用者は強制されたセッションIDに気づかずログインしてしまうと、アカウントの不正利用といった被害を受けてしまいます。
そして、攻撃者はセッションの固定化に成功すると、利用者のログインIDやパスワードを知らずとも利用者の個人情報の閲覧や変更などの操作が可能になります。
こういった被害を防ぐにはサイト自体の設定・設計やセッション管理方法を見直し、安全な状態になっていることを確認することをお勧めします。
関連項目
Session fixation Software Attack | OWASP Foundation JVNDBRSS
