セッション | Security Atlas

先に読むと理解しやすい記事：HTTP・HTTPS / Cookie

複数の通信を同じ利用者に結び付ける

セッションは、複数のHTTPリクエストを同じ利用者のやり取りとして扱うための仕組みです。HTTPの一回ごとの通信だけでは、直前のログイン結果が自動的に次の通信へ引き継がれません。アプリが識別用の値などを使って結び付けます。

代表的な方法では、サーバーがランダムなセッションIDと利用者IDの対応を保存し、ブラウザにはセッションIDだけをCookieで渡します。次のリクエストでブラウザがIDを送ると、サーバーは保存済みの対応を調べ、ログイン済みの利用者を特定します。

利用者がパスワードをサーバーへ送ると、サーバーは登録済みのパスワードハッシュと照合します。成功したら新しいセッションIDを作り、対応する利用者と期限を保存してから、Set-Cookieでブラウザへ渡します。

マイページ取得時には、ブラウザがCookieヘッダーにIDを付けます。サーバーはIDの存在、有効期限、無効化の有無を調べ、対応する利用者のデータを返します。Cookieに書いてある利用者名を無条件で信用する処理とは異なります。

ブラウザが持つIDは入力です。利用者と権限の判断はサーバーが行います。

Cookieはブラウザに保存される値です。この方式のセッション情報は、サーバーのデータベースや専用の保存領域に置きます。サーバーが複数台なら、同じ情報を参照できるようにするなど配置も設計します。

セッションという名前でも、必ずこの方式とは限りません。署名したデータをブラウザへ保存する方式もあります。どの方式でも、ブラウザから来た値を何で検証し、盗まれた値をどう無効にするかを確認します。

説明用の例として、サーバーログにセッションIDを出力し、そのログを攻撃者が読める状態を考えます。攻撃者がIDを自分のリクエストに付けると、サーバーは被害者のログイン状態として扱い、非公開データを返すおそれがあります。

IDは認証情報として保護します。推測しにくい乱数を使い、HTTPSで送り、CookieにはSecure・HttpOnlyなどを指定します。ログへ実値を残さず、XSSやCSRFの対策も組み合わせます。IPアドレスの一致だけで本人とは断定しません。

ログインや権限変更の後にはIDを再発行し、以前のIDを使えなくします。攻撃者が事前に知っていたIDを被害者に使わせ、ログイン後も同じIDが有効だと、攻撃者が被害者の状態を利用できるためです。これはセッション固定の問題です。

ログアウトではサーバー側でIDを無効にし、Cookieも消します。無操作で切れる期限と、操作を続けても切れる最長期限をサーバーで管理します。パスワード変更時に他端末のセッションを残すかも決めます。

確認問題：Cookieを削除するだけで、盗まれたIDも無効になるでしょうか。答えはなりません。そのブラウザが送らなくなるだけなので、サーバー側でIDを受け付けなくする必要があります。

自分の検証環境で、ログアウト後に旧IDを再使用しても認証が必要になるか確認します。ブラウザのセッション復元もあり得るので、ウィンドウを閉じる動作だけを失効処理の代わりにはしません。

未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。