「セッション」とは
セッションとは、ユーザーがログインしてからログアウトするまでの一連のやり取り（状態）を結びつけるサーバー側の概念です。
一般的には セッション識別子（Session ID / トークン） をクライアントが各リクエストで送ることで、サーバーがそのユーザーの状態を識別します。
安全なセッション管理とは、これらのトークンを「安全に発行・保管・回転・検証・無効化」することを意味します。
不適切なセッション実装に対する代表的な攻撃（仕組みと事例）
以下は頻出かつ影響が大きい攻撃手法です。
1. セッションハイジャック（トークン窃取）
何が起きるか： 攻撃者が有効なセッショントークンを盗み、利用者になりすます。
手段： TLS未使用での盗聴、XSS による cookie 抜き取り、マルウェア、MITM、あるいは予測可能なトークン値。
影響： セッション有効期間中の完全なアカウント乗っ取り。
2. セッション固定（Session Fixation）
何が起きるか： 攻撃者が既知のセッション ID を被害者に使わせ、被害者がログインした後にその ID を使ってアクセスする。
手段： 攻撃者が URL パラメータや別サブドメイン経由で SID を与え、サーバーがログイン後に SID を再発行しない場合に成立。
対策： 認証（ログイン）の際に必ずセッション ID を再生成すること。
3. XSS → トークン窃取
何が起きるか： XSS ペイロードが document.cookie を読み取り、攻撃者のサーバーに送る。
重要点： HttpOnly が設定されていない cookie は JS から読めるため危険。
対策： 出力エスケープ、CSP、HttpOnly cookie。
4. CSRF（クロスサイトリクエストフォージェリ）
何が起きるか： ブラウザが自動的に送る認証 cookie を利用して、第三者が被害者の権限で状態変更リクエストを発行する。
対策： SameSite 属性、Anti-CSRF トークン、カスタムヘッダ要求（例：X-Requested-With）など。
5. リプレイ攻撃（Token Replay）
何が起きるか： 取得したリクエスト／トークンを再送（再生）して、同じ操作や再認証を試みる。
対策： ワンタイム nonce、タイムスタンプ、短命トークン、サーバー側でのリプレイ検出。
6. セッション ID の予測／総当たり
何が起きるか： トークンが短い・弱い乱数で生成されていると推測され、有効なトークンを当てられる。
対策： 暗号学的に安全な RNG で十分なエントロピーを持つトークンを生成する。
7. JWT（Stateless トークン）特有の落とし穴
問題点： 長く有効な JWT を使うと取り消し（revocation）が難しい、alg 脆弱性（none を受け入れる等）、署名検証漏れ、ペイロードに機密情報を入れる、LocalStorage に入れて XSS に弱くなる等。
対策： 署名を必須にする、alg を固定して検証、短命のアクセストークン + セキュアなリフレッシュトークン、取り消し戦略（ブラックリストなど）。
脆弱性の検出・テスト方法
-
Cookie 属性確認：
Secure/HttpOnly/SameSiteが設定されているかを確認 - セッション固定テスト： ログイン前に自分で SID をセットしてログイン後に SID が変更されるか確認。変更されなければ脆弱
- トークンの予測性： 多数の SID を収集してパターンやエントロピーを解析
-
XSS テスト： 標準的な XSS ペイロードで脆弱性を確認し、
HttpOnly無しで cookie が読めるか確認 - リプレイテスト： 有効なリクエストをキャプチャしてログアウト後や一定時間後に再送し受理されるか確認
-
JWT チェック：
algがnoneでないか、署名検証・exp検証が正しく行われているか、機密情報が入っていないかを確認
具体的な対策とベストプラクティス（チェックリスト）
コア：セッション／トークンの取り扱い
- 暗号学的に安全な RNG で十分な長さのセッション ID を生成
- ログインや権限昇格時にセッション ID を再生成（rotation）
- ログアウト時はサーバー側セッションを完全に破棄
Cookie 設定（Cookie ベースの場合）
-
Secure— HTTPS のみで送信 -
HttpOnly— JavaScript からアクセス不可 -
SameSite=StrictまたはLax— CSRF リスクを低減（Lax は一般的なバランス） -
Path/Domainを適切に限定し、Max-Age／Expiresを設定
セッション寿命と回転
- アイドルタイムアウト（一定時間操作がないと切る）と絶対有効期限の両方を設ける
- 長時間必要なら短命アクセストークン＋リフレッシュトークン方式を採用し、リフレッシュトークンは厳格に管理（再利用検出、リボーク機構）
認証強化
- 重要アカウント／操作には MFA を必須にする
- パスワード変更や重要操作時に再認証を要求する
XSS と CSRF の防御
- XSS：出力の適切なエスケープ、CSP の導入、入力バリデーション
- CSRF：
SameSite、フォームごとの CSRF トークン、カスタムヘッダ必須化
ロギングと検知
- セッション作成・破棄・異常な再利用（別 IP / UA からのアクセス）をログに残し、異常検出（例：突然の国・IP 変更）でアラート。
- セッション関連のエンドポイントに対するレート制限を設定。
JWT 特有の対策
- 強い鍵で署名、
alg: noneを拒否、aud/iss/expを検証する。 - アクセストークンは短命にし、リフレッシュトークンを httpOnly セキュア cookie に保存する等の設計を検討。
- リフレッシュトークンに対してはサーバー側での取り消し管理を持つ（ブラックリストや DB ベースの有効化/無効化）。
最小限の安全な設定例（Cookie ベース）
Set-Cookie: session=<値>; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600
運用例：
- ログイン時：サーバーでセッション作成 → セッション ID を発行 → 直ちに新しいセッション ID に再生成（セッション固定防止）
- ログアウト時：Cookie を削除しサーバー側セッションも破棄
すぐに実行できる簡易検証チェックリスト
- 認証用 cookie に
Secure/HttpOnly/SameSiteがあるか。 - ログイン後にセッション ID が再生成されているか（セッション固定対策）。
- ログイン前に自分でセットした cookie がそのまま認証済みになるか（固定テスト）。
- キャプチャしたリクエストをログアウト後に再送しても受理されるか（リプレイテスト）。
- JWT を使っている場合：
alg/署名/exp検証・取り消し戦略の確認。
参考
- OWASP — Session Management Cheat Sheet（セッション運用の詳細ガイド）
- OWASP — Session Fixation / Session Hijacking の説明ページ
- OWASP — JSON Web Token（JWT）Cheat Sheet（JWT の落とし穴と対策）
- MDN — Using HTTP cookies（
Set-Cookieの仕様と SameSite の挙動） - OWASP Web Security Testing Guide — Session Management Testing（具体的なテスト手順）