Session Management

セッション管理（Session Management）とは、Webアプリケーションにおいてユーザーの認証状態や操作の文脈（コンテキスト）を、複数のHTTPリクエストにわたって維持・追跡するための仕組みです。HTTPはステートレス（状態を持たない）プロトコルであるため、ユーザーがログインした後の状態を維持するには、セッションIDやトークンなどの識別子をサーバーとクライアント間でやり取りする必要があります。

セッション管理には大きく分けてステートフル方式（サーバー側にセッション情報を保存し、CookieでセッションIDを管理）とステートレス方式（JWT等のトークンにセッション情報を含めてクライアント側で保持）があります。それぞれにメリット・デメリットがあり、アプリケーションの要件に応じた選択が求められます。

セッション管理の不備はセッションハイジャック（攻撃者が他人のセッションを奪取する攻撃）やセッション固定攻撃（攻撃者が指定したセッションIDを被害者に使用させる攻撃）など、深刻なセキュリティインシデントに直結します。適切なセッション管理は、Webアプリケーションセキュリティの基盤です。

セッションID生成の要件

安全なセッションIDは、十分なランダム性（エントロピー）を備えている必要があります。OWASP（Open Web Application Security Project）では、セッションIDに最低128ビットのエントロピーを推奨しています。暗号学的に安全な疑似乱数生成器（CSPRNG）を使用し、予測不可能なIDを生成することが不可欠です。

セッションIDが推測可能であったり、連番であったりすると、攻撃者はブルートフォースやセッションIDの列挙によって他のユーザーのセッションにアクセスできてしまいます。フレームワークが提供する標準的なセッション管理機能を使用し、独自実装は避けるべきです。

Cookie属性によるセッション保護

• HttpOnly：JavaScriptからのCookieアクセスを禁止し、XSS攻撃によるセッションID窃取を防止する
• Secure：HTTPS接続時のみCookieを送信し、通信経路上での盗聴を防止する
• SameSite：クロスサイトリクエスト時のCookie送信を制御する。Strict（完全に禁止）、Lax（ナビゲーション以外を禁止、デフォルト）、None（許可、Secureが必須）の3段階
• Path：Cookieが送信されるパスを制限する。アプリケーションのルートパスに設定するのが一般的
• Domain：Cookieが送信されるドメインを指定する。サブドメインを含めるかどうかの制御に使用

JWT（JSON Web Token）

JWTはJSON形式のクレーム（主張）を安全に伝達するための規格（RFC 7519）で、ステートレスなセッション管理に広く利用されています。JWTはヘッダー（アルゴリズム情報）、ペイロード（ユーザー情報や有効期限などのクレーム）、署名の3部分で構成され、Base64URLエンコードされてドット（.）で連結されます。

JWTの署名アルゴリズムには、HMAC-SHA256（HS256、共有鍵方式）やRSA-SHA256（RS256、公開鍵方式）などがあります。リフレッシュトークンは、アクセストークンの有効期限を短く保ちつつ、ユーザーの再認証なしに新しいアクセストークンを発行するための仕組みです。アクセストークンは短期間（例：15分）、リフレッシュトークンは長期間（例：7日）の有効期限を設定するのが一般的です。

セッション固定攻撃（Session Fixation）

セッション固定攻撃は、攻撃者が事前に取得したセッションIDを被害者に強制的に使用させ、被害者がログインした後にそのセッションIDを使って被害者になりすます攻撃です。攻撃者は、URLパラメータやCookieの操作によって、被害者のブラウザに特定のセッションIDをセットします。

対策として、ログイン成功時に必ずセッションIDを再生成（リジェネレーション）することが重要です。古いセッションIDを無効化し、新しいIDを発行することで、攻撃者が事前に仕込んだセッションIDは使用できなくなります。

セッションハイジャック

セッションハイジャックは、正規ユーザーのセッションIDを窃取し、そのユーザーになりすましてWebアプリケーションにアクセスする攻撃の総称です。主な手法として、ネットワークの盗聴（スニッフィング）、XSSによるCookie窃取、マルウェアによるCookie窃取、セッション予測（IDの推測）などがあります。

近年ではInfoStealerマルウェアによるセッションCookieの窃取が大きな脅威となっており、多要素認証を突破してアカウントを乗っ取るケースが増加しています。

アイドルタイムアウトと絶対タイムアウト

アイドルタイムアウトは、ユーザーが一定時間操作を行わなかった場合にセッションを自動的に無効化する仕組みです。一般的には15分〜30分に設定されます。絶対タイムアウトは、セッションの作成からの経過時間に基づいて強制的にセッションを終了させるもので、通常8時間〜24時間に設定されます。

両方のタイムアウトを組み合わせることで、長時間のセッション維持によるリスクと、セッションCookieが窃取された場合の悪用期間を最小限に抑えられます。

• 01
  セッションCookieに適切な属性を設定：すべてのセッションCookieにHttpOnly、Secure、SameSite=Lax（またはStrict）属性を設定してください。これにより、XSS攻撃によるCookie窃取、通信経路上の盗聴、CSRF攻撃のリスクを大幅に低減できます。
• 02
  認証時のセッションID再生成：ログイン成功時、権限昇格時、パスワード変更時には必ずセッションIDを再生成してください。古いセッションIDは即座に無効化し、セッション固定攻撃を防止しましょう。
• 03
  JWTの安全な実装：JWTを使用する場合は、アルゴリズムを明示的に検証し、noneアルゴリズムを許可しないでください。アクセストークンの有効期限は短く（15分以下）設定し、リフレッシュトークンはサーバー側で無効化可能な仕組みを実装しましょう。秘密鍵は十分な長さ（256ビット以上）のものを使用してください。
• 04
  適切なタイムアウトの設定：アイドルタイムアウト（15〜30分）と絶対タイムアウト（8〜24時間）の両方を設定してください。機密性の高いアプリケーションではより短い期間を設定し、ユーザーの利便性とセキュリティのバランスを考慮しましょう。
• 05
  安全なログアウト処理の実装：ログアウト時にはサーバー側のセッションデータを完全に破棄し、クライアント側のセッションCookieも削除してください。JWTの場合はトークンのブラックリスト（拒否リスト）を実装し、ログアウト後のトークン使用を防止しましょう。
• 06
  セッション異常検知の実装：同一セッションIDの複数IPアドレスからの同時使用、急激なジオロケーションの変化、異常なUser-Agentの変更を検知し、自動的にセッションを無効化する仕組みを導入してください。不審なセッション活動をリアルタイムで監視・アラートすることが重要です。