// シス担のミカタ
Webアプリケーション攻撃

セッション固定攻撃 せっしょんこていこうげき

セッションIDセッションハイジャックCookie認証XSSWebセキュリティ
セッション固定攻撃について教えて

簡単に言うとこんな感じ！

攻撃者があらかじめ「合鍵」を用意して、あなたにその合鍵を使わせるイメージだよ。ログインするとその合鍵でドアが開くから、攻撃者も同じ合鍵で入り放題になっちゃうんだ！

セッション固定攻撃とは

Webサービスにログインすると、サーバーは「あなたが誰か」を覚えておくためにセッションIDと呼ばれる識別番号を発行します。ブラウザはこのIDをCookieなどに保存し、以降のリクエストに添付することでログイン状態を維持します。通常、このIDはログインのたびにサーバーがランダムに生成するため、第三者が推測するのは困難です。

セッション固定攻撃（Session Fixation Attack） は、攻撃者が「自分で用意したセッションID」を被害者に先に使わせておき、被害者がログインした瞬間にそのIDを乗っ取る手口です。攻撃者はIDを盗む必要がなく、最初から知っているIDを被害者に押し付けるという点が通常のセッションハイジャックとの大きな違いです。

ログイン前後でセッションIDを変更しない（再生成しない）Webアプリケーションが狙われます。一見地味な脆弱性ですが、成功すると攻撃者が被害者のアカウントに完全にアクセスできるため、個人情報の窃取や不正操作につながる深刻なリスクです。

攻撃の仕組みとステップ

セッション固定攻撃は大きく3つのフェーズで構成されます。

フェーズ攻撃者の行動被害者の状態
① ID取得攻撃対象サイトに未ログインでアクセスし、有効なセッションIDを入手するまだ何もしていない
② ID埋め込み細工したURLやCookieに取得したIDを仕込み、被害者にアクセスさせる攻撃者が用意したIDでサイトを閲覧し始める
③ 乗っ取り被害者がログインするのを待つログイン完了。IDは変わらないまま認証済み状態になる
攻撃者                        被害者                      サーバー
  |                              |                            |
  |--- ① GET /login ------------>|                            |
  |<-- セッションID: ABC123 ------|                            |
  |                              |                            |
  |--- ② 細工URL送付 ----------->|                            |
  |    (session=ABC123 付き)     |                            |
  |                              |-- ③ GET /login?session=ABC123 -->|
  |                              |<-- セッションID: ABC123 --------|
  |                              |                            |
  |                              |-- ④ POST /login (ID/PW) -->|
  |                              |<-- ログイン成功 (ABC123のまま)|
  |                              |                            |
  |--- ⑤ ABC123でアクセス ------>|                            |
  |<-- 被害者として認証済み -------|                            |

「固定」という名前の覚え方

「自分で釘を打つ（固定する）から Session Fixation」 と覚えましょう。通常の攻撃はIDを「盗む」ですが、これは自分で決めたIDを相手に「打ち込む」イメージです。Fix＝釘で固定、がポイントです。

IDを被害者に使わせる主な手口

  • URLパラメータ埋め込み: https://example.com/login?sessionid=ABC123 のようなリンクをメールやSNSで送る
  • HTTPレスポンス改ざん: 中間者攻撃やサブドメインの脆弱性を利用してCookieを上書きする
  • XSS（クロスサイトスクリプティング）と組み合わせる: スクリプト注入でCookieを強制的に書き換える

歴史と背景

  • 2002年頃: セッション管理の不備が多くのWebアプリで発覚し始める。当時はセッションIDを固定してしまう実装が珍しくなかった
  • 2004年: Mitja Kolšek（WASCメンバー）がセッション固定攻撃を体系的に整理した論文を公開。脆弱性として広く認知される
  • 2007年: OWASP（Webセキュリティの国際標準化団体）がTop 10にセッション管理の問題を掲載し、認証後のセッションID再生成を推奨として明記
  • 2010年代: PHPやRailsなどの主要フレームワークがログイン後の自動セッション再生成をデフォルト機能として実装。被害件数は減少傾向に
  • 現在: フレームワークの適切な利用で防ぎやすくなったが、自前実装やレガシーシステムでは依然リスクが残る

セッション固定攻撃 vs 関連する攻撃の比較

セッションを悪用する攻撃はいくつかあり、混同しやすいため整理します。

セッション系攻撃の比較 セッション固定攻撃 セッションハイジャック CSRF 方法 攻撃者が事前に IDを「用意・押付」 方法 通信傍受などで IDを「盗む」 方法 IDは不要。被害者の ブラウザを「操作」 タイミング ログイン「前」に 仕掛けを行う タイミング ログイン「後」の IDを奪取 タイミング ログイン「済み」の 状態を利用 主な対策 ログイン後に セッションID再生成 主な対策 HTTPS通信の徹底、 Secure Cookie属性 主な対策 CSRFトークン、 SameSite Cookie 難易度 中（IDを渡す 手段が必要） 難易度 中〜高（傍受に 技術が要る） 難易度 低〜中（対策漏れ で比較的容易）

具体的な防御策（発注・選定時のチェックポイント）

開発会社やSaaS製品を選ぶ際、以下の対策が実装されているかを確認しましょう。

対策内容重要度
ログイン後のセッションID再生成ログイン成功時に古いIDを破棄し、新しいIDを発行する★★★ 最重要
HttpOnly属性JavaScriptからCookieを読めなくすることでXSSとの組み合わせを防ぐ★★★
Secure属性HTTPS通信のみCookieを送信し、平文での漏洩を防ぐ★★★
セッション有効期限の設定長時間放置されたセッションを自動で無効化する★★
URLパラメータでのID受け取り拒否URLにセッションIDが含まれていても無視する実装★★

関連する規格・RFC

規格・RFC番号内容
RFC 6265HTTP State Management Mechanism（CookieのSecure・HttpOnly属性の仕様）
OWASP Session Management Cheat Sheetセッション管理のベストプラクティス集（ログイン後の再生成を明示）
OWASP Top 10 A07:2021Identification and Authentication Failures（認証・セッション管理の失敗）
CWE-384Session Fixation（共通脆弱性列挙の固有ID）

関連用語