概要
基本的なセッションの運用方法についてまとめた。
前提
以下の記事の続きとなる。
概要 認可エラーをハンドリングする方法についてまとめた。 前提 以下の記事の続きとなる。
セッションの役割
セッションとは、Webアプリケーションにおいて「ユーザーの状態（特に認証情報）を一時的に保持する仕組み」のこと。
HTTPは本来ステートレス（状態を持たない）なので、ログイン状態などを維持するためにセッションIDが必要とする。
パスワード認証や２段階認証などはログイン時だけ使用されるが、ログイン後はセッションIDだけでユーザーの認証状態を保持する。
セッションIDは「一時的な鍵」として機能し、リクエスト毎にクライアントとサーバー間で照合される。
サーバー側でこの鍵が一致することによって、「本人がリクエストしている」と判断される設計になっている。
セッションIDの運用
セッションIDは基本的に以下のような運用がある。
・再生成型（安全性が高い）： 初回アクセス時にセッションIDを発行し、本人認証後に再度セッションIDを発行する
＜固定型のイメージ＞
＜再生成型のイメージ＞
脅威と管理
セッションIDが第三者に盗まれると、本人になりすまして操作されるリスクがある。
そのため、セッションIDが漏洩する脅威に備えた対策を行うことが重要になる。
脅威の種類
主に以下のような脅威がある。
・セッション固定攻撃（事前にIDを仕込む）
セッションハイジャック
セッションハイジャックとは、セッションIDを盗み見る行為のこと。
具体的には以下のような手法がある。
| 種類 | 内容 |
|---|---|
| 盗聴 | 公共Wi-FiなどでHTTP通信を行った場合、通信内容が暗号化されていないため、ツールによって傍受される可能性がある。 傍受された通信からCookieを参照し、平文で送られたセッションIDが盗まれる。 |
| XSS （クロスサイトスクリプティング） |
攻撃者がWebページに悪意あるJavaScriptを埋め込む。 ユーザーがそのページを開くと、JavaScriptの処理が実行されてCookieのセッションIDが攻撃者のサーバーに送信される。 |
| 物理的手段 | ログインしたままの端末を放置してしまうことで、第三者が物理的に認証状態を不正利用する。 |
セッション固定攻撃
攻撃者があらかじめ用意したセッションIDをユーザーに使用させ、ログイン後にそのIDを使ってなりすます行為のこと。
具体的には以下のような流れで攻撃される。
| 手順 | 概要 | 具体例 |
|---|---|---|
| ① | 攻撃者がセッションIDを取得 | 攻撃者が対象のWebサイトにアクセスし、認証前のセッションID（例：JSESSIONID=ABC123）を取得する。 |
| ② | 取得したセッションIDをユーザーに送信 | 攻撃者が以下のようなURLをメールやSNSで送信する。 例）： http://example.com/login?jsessionid=ABC123 ユーザーがこのリンクをクリックすると、セッションIDがブラウザにセットされる。 |
| ③ | ユーザーが認証を行う | 予め用意しておいたセッションIDがサーバー側で「認証済み」状態となる。 |
| ④ | 攻撃者が同じセッションIDを利用 | 攻撃者が同じセッションIDを利用してブラウザにアクセスすると、既に認証済みの状態で操作可能となる。 |
防衛策
セッションIDの盗難リスクに対して、以下のような防衛策を講じる必要がある。
| 防衛策 | 対応内容 |
|---|---|
| セッションタイムアウト設定 | 一定時間操作されない場合はセッションを破棄することで、長期利用による乗っ取りを防止する。 セッションハイジャック対策となる。 |
| 同時ログイン制御 | 同一ユーザーの同時セッション数を制限することで、異常な多重利用を検知する。 セッションハイジャック、セッション固定攻撃対策となる。 |
| HTTPSの強制 | 通信を暗号化することで、ネットワーク盗聴を防止する。 セッションハイジャック対策となる。 |
| HttpOnly属性の付与 | JavaScriptからCookieを参照できなくすることで、XSSによるセッションID漏洩を防止する。 セッションハイジャック対策となる。 |
| URL埋め込み禁止 | セッションIDがURLに露出することを禁止することで、セッションIDの共有を防止する。 セッション固定攻撃対策となる。 |
まとめ
☑ セッションIDは、ユーザーの認証状態を維持するための仕組みである
☑ セッションIDが第三者に盗まれると、本人になりすましてサイトを利用される恐れがある
☑ セッションIDの漏洩を防ぐためのセキュリティ対策が不可欠となる