IT用語集 2023/10/27

セッションフィクセーションとは？わかりやすく10分で解説

コラム

セッションフィクセーションとは？

セッションフィクセーション（Session Fixation）は、Webアプリケーションにおける攻撃手法の一つです。攻撃者があらかじめ把握しているセッションIDを被害者に使わせ、その後に被害者がログインすると、同じセッションIDを使ってログイン済み状態を不正利用できるようになる場合があります。要点は、セッションIDを盗むのではなく、攻撃者が知っているセッションIDを被害者に使わせる点にあります。

セッションIDは、サーバーが「このリクエストはどの利用者の操作か」を識別するための情報です。ログイン前の段階で攻撃者がセッションIDを固定でき、さらにアプリケーションがログイン時にセッションIDを再生成しない実装になっていると、被害者のログイン後にそのIDが有効なログイン済みセッションとして扱われ、攻撃が成立します。

セッションフィクセーションのイメージ

攻撃の目的

主な目的は、被害者のログイン済みセッションを不正に利用し、その権限で操作することです。攻撃者はまず、自分が把握できるセッションIDを確保します。そのうえで、そのセッションIDを被害者に使わせる導線を用意し、被害者がその状態のままログインするのを待ちます。

典型例としては、URLパラメータにセッションIDが含まれる設計を悪用したリンク送付、外部サイトからの誘導、共有端末やキオスク端末のように複数人が同じ環境を使う状況の悪用が挙げられます。被害者がそのままログインし、アプリケーション側がセッションIDを再生成しなければ、攻撃者は同じセッションIDを使ってログイン済み状態を再現できるおそれがあります。

攻撃例

たとえば、攻撃者が事前に取得したセッションIDを含むリンクを被害者にクリックさせ、そのままログインさせるケースです。ログイン後も同じセッションIDが有効なままだと、攻撃者は後から同じIDでアクセスし、被害者のログイン済みセッションを不正に利用できます。オンラインバンキングや業務システムのように、ログイン後に重要な操作ができるサービスでは影響が大きくなります。

セッションフィクセーションの仕組み

セッションIDとは

セッションIDは、サーバーとクライアントのやり取りをひも付けるための識別子です。HTTPは基本的にステートレスなため、ログイン状態やカート情報などの状態を維持するには、サーバーがクライアントへセッションIDを渡し、以後のリクエストで同じIDを送ってもらう必要があります。

セッションIDの伝達手段として一般的なのはCookieです。各リクエストでCookieが送信され、サーバーはそのIDをキーにサーバー側のセッション情報を参照します。そのため、セッションIDが漏えいしたり固定されたりすると、ログイン状態の正当性が崩れます。

攻撃者によるセッションIDの準備と利用

セッションフィクセーションでは、攻撃者は被害者がログインする前に、攻撃者が把握できるセッションIDを被害者に持たせようとします。ここで重要なのは、攻撃者が被害者のセッションIDを盗む必要が必ずしもない点です。攻撃者が知っているIDを被害者に使わせることができれば、攻撃の条件がそろいます。

この攻撃が成立しやすいのは、ログイン前後で同じセッションIDが使われる場合です。逆に、ログイン成功時にセッションIDを再生成し、旧IDを無効化していれば、攻撃者が事前に知っていたIDは意味を持ちません。

攻撃の手順

流れを整理すると、次の3段階です。

1）攻撃者がセッションIDを確保する：Webアプリケーションにアクセスし、アプリが発行したセッションIDを取得します。

2）被害者にそのIDを使わせる：セッションIDが反映される形で被害者を誘導し、その状態のままログインさせます。

3）攻撃者が同じIDでアクセスする：被害者がログインした結果、そのセッションIDがログイン済みとして有効なままなら、攻撃者も同じIDでログイン済みの権限を得られます。

したがって、対策の中心は「ログイン時にセッションIDを切り替える」「セッションIDを外部から固定しにくい伝達方法にする」「固定されても成立しない設計にする」という3点に集約されます。

他の脅威との違い

セッションハイジャックとの違い

セッションフィクセーションは、セッションIDを固定して使わせる攻撃です。一方、セッションハイジャックは、被害者が使っているセッションIDを盗むことで成立します。盗み方としては、通信の盗聴、XSSによるCookieの窃取、端末マルウェア、ログの漏えいなどがあります。

両者は、最終的に攻撃者が有効なセッションIDを利用できる点では似ていますが、成立条件は異なります。セッションフィクセーションは、ログイン時のセッション再生成不足など、実装や設計の不備に依存しやすい攻撃です。これに対し、セッションハイジャックでは、セッションIDの漏えい経路をふさぐ対策がより重要になります。

他のWebアプリケーション脅威との関係

Webアプリケーションには、XSS、CSRF、SQLインジェクションなど多様な脅威があります。セッションフィクセーションは、その中でも「セッション管理」に関わる脅威です。XSSのような別の脆弱性と組み合わさると、被害が拡大しやすくなります。

たとえば、XSSがあるとセッションIDの窃取につながりやすくなりますし、CSRF対策が弱いと、ログイン済みセッションを使った不正操作が成立しやすくなります。したがって、セッションフィクセーションだけを個別に見るのではなく、Webアプリ全体の防御設計の中でセッション管理を見直す必要があります。

セッションフィクセーションの対策

ログイン時のセッションID再生成

最も重要なのは、ログイン成功時にセッションIDを再生成し、旧セッションを無効化することです。これにより、攻撃者が事前に把握していたセッションIDが、ログイン後の有効セッションとして残らなくなります。

セッションIDをURLに含めない

セッションIDはCookieで管理し、URLに埋め込む設計は避けるのが基本です。URLに含めると、リンク共有、ブラウザ履歴、アクセスログ、Refererなどを通じて露出しやすくなり、固定化や漏えいの原因になります。

Cookie属性を適切に設定する

HTTPSを前提に、CookieにはSecure属性、HttpOnly属性、SameSite属性などを適切に設定します。これにより、盗聴、スクリプトからの参照、不要なクロスサイト送信のリスクを減らせます。

セッション管理を一貫して設計する

セッション管理では、「発行」「維持」「無効化」を切り分けずに一体で設計する必要があります。具体的には、推測しにくいセッションIDの生成、ログイン前後のセッション分離、適切なタイムアウト、ログアウト時の確実な無効化、権限変更時のセッション更新などが必要です。

また、重要操作には追加の再認証や多要素認証を組み合わせると、セッション単独に依存しない防御が実現しやすくなります。送金、設定変更、機密情報の閲覧などでは、この設計が有効です。

診断とレビューを継続する

セッション管理は、フレームワーク、ロードバランサ、SSO、CDN、WAFなど複数の構成要素の影響を受けやすい領域です。設計と実装の両面で確認しなければ、想定外の穴が残ることがあります。

特に、ログイン時のセッション再生成が確実に行われているか、URLパラメータやRefererにIDが露出しないか、プロキシやログにIDが残っていないかは、運用環境で見落とされやすい確認項目です。アプリ診断やペネトレーションテストを定期的に行い、変更のたびに再確認する必要があります。

個人と企業への影響

個人への影響

個人利用のサービスでは、アカウントの不正利用、個人情報の閲覧、なりすまし投稿、購買履歴の悪用などにつながる可能性があります。攻撃者がログイン済みの状態を利用できるため、本人確認の前提が崩れます。

企業への影響

企業では、顧客データの漏えい、業務システムの不正操作、事故対応コストの増加、監督官庁への対応、信用低下など、影響が技術面を超えて広がることがあります。ログイン済み状態を不正利用されるため、パスワードの漏えいと同等、あるいはそれ以上に深刻な問題になる場合もあります。

利用者教育だけでは不十分

利用者側では、怪しいリンクを開かない、共有端末で必ずログアウトする、ブラウザを最新に保つといった基本的な対策が有効です。ただし、セッションフィクセーションはアプリケーション側の実装不備で成立しやすいため、利用者教育だけで防ぐことはできません。

企業側は、セッション再生成の必須化、Cookie属性の標準化、ログのマスキング、診断の定期実施などを開発・運用ルールとして定着させる必要があります。

まとめ

セッションフィクセーションは、攻撃者が事前に把握したセッションIDを被害者に使わせ、ログイン後のセッションを不正利用する攻撃です。成立の中心にあるのは、ログイン時にセッションIDが再生成されず、ログイン前のセッションがそのまま有効になる実装です。

対策として優先すべきなのは、ログイン成功時のセッションID再生成と旧セッションの無効化、セッションIDをURLに露出させない設計、HTTPSの徹底、Cookie属性の適切な設定です。さらに、重要操作での追加認証や異常検知を組み合わせることで、セッション単独に依存しない防御がしやすくなります。

セッション管理はWebアプリケーションの根幹です。設計、実装、運用のいずれかが欠けると、攻撃の成立条件がそろいやすくなります。基本原則を押さえたうえで、診断やレビューを継続し、変更時にも安全性が維持される運用を整備してください。