セッションハイジャックとは
セッションハイジャックは、被害者の有効なセッションIDを攻撃者が使う攻撃です。
完全に防ぐ設計と同時に、盗まれた可能性を検知し、被害を狭める設計が重要です。
セッションIDが盗まれる入口:
- XSS
- 通信経路の問題
- ログや画面共有への露出
- 端末のマルウェア
- サブドメインやCookie設定の不備
- 開発環境での雑な取り扱い
HttpOnly や Secure は重要ですが、それだけで全てを防げるわけではありません。
見るべきシグナル
セッション不正利用を疑う材料には、次のようなものがあります。
| シグナル | 例 |
|---|---|
| IPの急変 | 日本から数分後に海外IP |
| User-Agentの変化 | Safariからcurlに変わる |
| 端末の変化 | iPhoneからWindowsへ変わる |
| 地域の不自然な移動 | 物理的に不可能な速度 |
| 高リスク操作 | パスワード変更、メール変更、決済 |
| 古いtokenの再利用 | ローテーション済みRemember tokenが使われる |
ただし、どれも単体では確定できません。VPN、モバイル回線、企業プロキシ、ブラウザ更新で変わることがあります。
IPを縛りすぎない
IPアドレスでセッションを完全固定すると、正規ユーザーが落ちやすくなります。
起きやすい問題:
- モバイル回線でIPが変わる
- 企業ネットワークで出口IPが変わる
- VPN利用者がいる
- IPv4/IPv6で経路が変わる
そのため、IPは「即ブロック」より「リスクスコアの材料」にする方が扱いやすいです。
IP国が変わった -> リスク加点
User-Agentも変わった -> さらに加点
重要操作を実行 -> 再認証
User-Agentの扱い
User-Agentは端末やブラウザの目安になりますが、偽装できます。
使い方:
- セッション作成時のUser-Agentをハッシュで保存
- 大きく変わったらリスクとして扱う
- 変化だけで即ログアウトしない
- 管理画面に端末名として表示する
保存例:
{
"userId": "user_001",
"userAgentHash": "sha256:abcd...",
"deviceLabel": "Chrome on macOS",
"createdAt": "2026-06-27T10:00:00Z"
}
生のUser-Agentを長期保存する場合は、ログ量やプライバシーにも注意します。
重要操作で再認証する
すべての怪しい挙動を即ログアウトにすると、誤検知で使いにくくなります。
現実的には、重要操作で再認証を求める設計が有効です。
再認証を検討する操作:
- パスワード変更
- メールアドレス変更
- 支払い方法変更
- 退会
- APIキー発行
- 管理者権限操作
- 保護者情報や個人情報の変更
通常閲覧は通しつつ、重要操作前にパスワード再入力やMFAを求めます。
セッション一覧と通知
ユーザーが自分で気づけるUIも重要です。
表示例:
| 端末 | 最終利用 | 場所の目安 | 操作 |
|---|---|---|---|
| Chrome on macOS | 5分前 | Tokyo | この端末 |
| Safari on iPhone | 2日前 | Osaka | ログアウト |
新しい端末でログインしたときに通知する設計もあります。
新しい端末でログインしました
Chrome on Windows
2026-06-27 10:30
心当たりがなければ全端末ログアウトしてください
通知は不正検知だけでなく、ユーザーに確認機会を作る意味があります。
ログ設計
セッション調査に必要なログは、最初から設計しておきます。
残すとよいもの:
- userId
- session id のハッシュまたは内部ID
- ログイン成功/失敗
- ログアウト
- Remember token利用
- IPのハッシュまたは短期保存
- User-Agentハッシュ
- 重要操作
- 失効理由
避けるもの:
- Cookieヘッダー全文
- セッションID平文
- access token平文
- refresh token平文
- パスワード
ログが漏れたときにセッションを再現できないようにします。
怪しいときの対応
リスクが高いと判断した場合の対応は段階化します。
| リスク | 対応 |
|---|---|
| 低 | ログだけ残す |
| 中 | 重要操作前に再認証 |
| 高 | そのセッションを失効 |
| 重大 | 全端末ログアウト、パスワード変更要求 |
一律に全員ログアウトではなく、影響範囲に応じて狭く止めます。
誤検知とのバランス
セキュリティ検知は強くするほど、正規ユーザーも止まりやすくなります。
誤検知が起きやすい例:
- 海外旅行
- VPN
- 学校や会社の共有ネットワーク
- モバイル回線
- ブラウザ更新
- プライバシー保護機能
そのため、「IPが変わったから即BAN」ではなく、複数シグナルを組み合わせます。重要操作だけ再認証にするなど、被害リスクとUXを分けて考えます。
まとめ
セッションハイジャック対策は、Cookie属性だけで終わりません。
- IP、User-Agent、地域、端末変化をリスク材料にする
- 単一シグナルで即ブロックしない
- 重要操作では再認証を求める
- セッション一覧と通知を用意する
- ログには秘密値を残さない
- 失効範囲を段階化する
「盗まれない設計」と「盗まれたかもしれない時に気づく設計」の両方が必要です。
