セッションハイジャック
Session Hijacking
概要（サマリー）
セッションハイジャックとは、セッションIDなどを不正に入手・悪用し、ログイン済みの利用者になりすます攻撃である。
入場時に本人確認した後で使う「再入場券」を、他人に奪われるようなものだ。
パスワードが漏れていなくても、ログイン状態を示す情報が悪用されると被害につながる場合がある。
詳細解説
ログイン済みを確かめる仕組み
Webサービスでは、ページを開くたびにパスワードを聞くと使いにくい。
そこで、ログイン後の状態をセッションとして管理する。
一般的な構成では、状態を識別するセッションIDを、認証用のCookieでやり取りする。
サービスは、受け取った識別情報を使って、どの利用者の操作かを判断する。
この識別情報が有効な間は、パスワードを入力せずに操作できる場合がある。
そのため、パスワードと同様に、慎重に扱う必要がある情報なのだ。
セッションIDを奪う方法
攻撃者は、マルウェアで端末から情報を盗んだり、Webページの弱点を悪用したりする。
保存されたパスワードやCookieを集めるインフォスティーラーが使われる場合がある。
暗号化されていない通信から漏れる場合や、記録へ誤って出力される場合もある。
XSSによって、JavaScriptから読み取れる認証用Cookieが盗まれるおそれもある。
認証用の情報をURLへ入れると、共有や履歴、記録を通じて漏れる原因になる。
Cookieが盗まれれば、どのサービスでも必ず乗っ取れるわけではない。
有効期限、端末との結び付け、サービス側の検知や再認証なども関係する。
二要素認証との関係
二要素認証は、ログイン時の本人確認を強くする対策だ。
しかし、その後に使う認証済みの情報が盗まれると、別の問題が生じる。
攻撃者が認証を済ませたセッションを悪用できれば、最初の確認を繰り返さずに済む場合がある。
これは、二要素認証のコードそのものを破っているとは限らない。
重要な操作の前に再認証する設計は、被害を抑える助けになる。
ログイン入口の強化と、認証後の状態の保護を、両方考える必要がある。
Cookieの保護設定
サービス側は、HTTPSを使い、認証用Cookieにも適切な属性を設定する。
次は属性の意味を示す見本であり、値は本物の識別情報ではない。
名前の __Host- は、Cookieをより厳しく扱うための接頭辞の例であり、この名前をそのまま使う必要はない。
Set-Cookie: __Host-session=example-value; Path=/; Secure; HttpOnly; SameSite=Lax
SecureはHTTPSの通信に送信を限定し、HttpOnlyはJavaScriptからの読み取りを制限する。
SameSiteはサイトをまたぐ送信を制限し、主にCSRFなどの軽減に役立つ。
これらは役割が異なり、単独で盗難や乗っ取りをすべて防ぐものではない。
端末の感染、XSSによる本人の画面上での不正操作、サーバー側の不備にも別途対応が必要だ。
作成から無効化まで管理する
ログイン成功時や権限が変わる際には、セッションIDを再発行する設計が重要だ。
ログイン前からの識別情報を、そのまま強い権限の状態へ持ち越さないためである。
一定時間での期限切れや、ログアウト時の無効化も必要になる。
端末からCookieを消すだけでなく、サービス側でも使えない状態にすることが重要だ。
パスワード変更時に既存のログインを失効させるかは、サービスの設計によって異なる。
被害対応では「変更したから全端末がログアウトしたはず」と決めつけず、機能を確認する。
CSRFとの違い
セッションハイジャックは、セッションの識別情報などを悪用して利用者になりすます攻撃だ。
一方、CSRFは、ログイン済みの利用者のブラウザに意図しない要求を送らせる攻撃である。
CSRFでは、攻撃者がセッションIDを盗み取らなくても成立する場合がある。
どちらも本人の権限が悪用されるが、操作を成立させる仕組みが異なる。
そのため、Cookieに属性を付けるだけで両方の対策が終わるわけではない。
セッション管理と、CSRFトークンや要求元の確認などを、それぞれの目的に合わせて設計する。
AIコーディングとの関係
AIにログイン機能を作らせるときは、「ログインできること」以外の条件も指定する。
たとえば「Cookieの属性、期限、ログイン時の再発行、ログアウト時の無効化を説明して」と依頼できる。
コードの確認では、ログアウトした識別情報が再利用できないかなどを確かめる。
AIに相談するときは、実際のCookieやセッションIDを貼らず、伏せた値と構成を示す。
よくある勘違い
パスワードを知られなければ乗っ取られない？
認証済みのセッションを悪用される場合がある。
パスワードと同じように、認証用Cookieなども保護する必要がある。
HttpOnlyを付ければXSSは無害？
JavaScriptからCookieを読み取る方法は制限できるが、画面上の不正操作までは防げない。
XSSそのものを防ぐ対策も必要だ。
パスワード変更だけですべて解決？
既存セッションやトークンが残る場合がある。
サービスの「すべての端末からログアウト」などの機能を確認し、端末の感染にも対応する。
まとめ
- セッションハイジャックは、ログイン済みを示す情報などを悪用する攻撃である。
- 二要素認証に加え、認証後の状態も保護する必要がある。
- HTTPS、Cookie属性、再発行、期限、無効化を組み合わせて設計する。
- CSRFとは成立の仕組みが異なり、対策も分けて考える。
情報ソース
より詳しくAIに聞いてみよう
- セッションハイジャックを、再入場券に例えて説明してください。
- セッションハイジャックとCSRFの違いを整理してください。
- Secure、HttpOnly、SameSiteが、それぞれ防ぐ危険と限界を教えてください。
- このアプリのセッション管理について、再発行・期限・無効化の観点で確認してください。
- AIにログイン機能を作らせる際の、セッション乗っ取り対策を含む依頼文を作ってください。