アカウントを乗っ取る「セッションハイジャック」とは?
パスワードだけでなく、本人確認後の「一時的な入館証」であるセッションも守る必要があります。
Webサービスでは、一度ログインすればページを移動するたびにパスワードを入力する必要はありません。サービスが「本人確認済みの利用者」と判断するためのセッション情報を使っているからです。
セッションハイジャックとは、この有効なセッションを攻撃者が不正利用し、本人になりすましてアクセスする攻撃です。パスワードそのものを知らなくても成立する場合があります。
セッションとは?
セッションは、Webサービスが一連の利用状態を関連付ける仕組みです。ログインに成功すると、サービスはブラウザやアプリへセッションIDやトークンを渡し、その後のアクセスで本人確認済みの状態を判別します。
最初の認証を「受付での本人確認」、セッション情報を「本人確認後に使う一時的な入館証」と考えると分かりやすいでしょう。セッション情報はCookieに保存されることがありますが、すべてのCookieがログイン用ではありません。
セッションハイジャックの仕組み
OWASPは、セッションIDの漏えい、取得、推測、総当たり、固定化などにより、攻撃者が利用者になりすます攻撃をセッションハイジャックとして説明しています。
パスワード漏洩では盗んだ認証情報で新しくログインしますが、セッションハイジャックでは本人がログインした後の有効なセッションを悪用します。その権限によっては、メールやクラウドファイルの閲覧・ダウンロード、登録情報の確認などが行われる可能性があります。
パスワード変更だけで解決する?
サービスによって、パスワード変更後も既存のセッションが直ちにすべて無効になるとは限りません。侵害が疑われる場合は、パスワード変更と「すべての端末からログアウト」の両方を確認します。
どのようにセッションを奪われる?
情報窃取型マルウェア
端末上のCookie、トークン、ブラウザデータなどを盗むマルウェアがあります。原因が端末に残れば、認証情報を変えても再び盗まれる可能性があります。
悪意のあるブラウザ拡張機能
閲覧ページやサイトデータへ広い権限を持つ拡張機能は、侵害された場合に大きなリスクとなります。提供元と権限を確認し、不要なものは削除します。
Webサイトの脆弱性
XSSなどが悪用されると、利用者のブラウザ上で不正処理が実行される場合があります。HttpOnlyはCookieの直接読み取りを制限しますが、XSSそのものを無害化する万能策ではありません。
暗号化されていない通信
HTTPで重要なセッション情報を送ると、通信経路から漏れる危険があります。OWASPは、セッション全体でHTTPSを使い、セッションCookieへSecure属性を設定するよう推奨しています。
共用端末とロック解除済み端末
ブラウザを閉じただけではログイン状態が残る場合があります。また第三者がログイン済み端末を操作できれば、セッション情報を盗まなくてもアカウントを使われる可能性があります。
セッション固定攻撃
関連する攻撃にセッション固定があります。攻撃者が把握しているセッションIDを被害者に使わせ、その状態でログインさせた後に同じIDを悪用します。サービス側では、ログインや権限変更時にセッションIDを新しくするなどの対策が必要です。
二段階認証やパスキーでも防げない?
多要素認証は、パスワードが漏れた後の新規ログインを防ぐ重要な対策です。パスキーもフィッシングへの耐性を高めます。
しかし、認証後の有効なセッション自体が盗まれれば、追加認証なしで利用できる場合があります。OWASPも、強い認証だけではCookie窃取への十分な対策にならないと説明しています。これは多要素認証やパスキーが無意味なのではなく、認証前と認証後の両方を守る必要があるという意味です。
公共Wi-FiやVPNとの関係
HTTPSが正しく使われていれば、同じWi-Fiの利用者がセッションCookieを簡単に読み取ることは難しくなります。証明書警告を無視せず、HTTPのログイン画面や偽サイトを使わないことが重要です。
VPNは通信経路の保護に役立ちますが、端末内のマルウェア、悪意ある拡張機能、XSS、共用端末に残ったセッションまでは防ぎません。
サービス側の主な対策
- セッション全体でHTTPSを必須にする
- 推測困難なセッションIDを使う
- CookieへSecure、HttpOnly、適切なSameSiteを設定する
- ログインや権限変更時にセッションIDを更新する
- アイドル時間と絶対時間の有効期限を設ける
- ログアウト時にサーバー側でも無効化する
- 重要操作で再認証を求める
- XSSやCSRFを防ぎ、不審なセッションを検知する
SameSiteは主にクロスサイトリクエストでのCookie送信を制限する属性です。Cookie窃取すべてを防ぐものではなく、各対策を組み合わせます。
利用者ができる8つの対策
- OS、ブラウザ、アプリを最新にする
- 提供元不明のアプリやAPKを入れない
- ブラウザ拡張機能を必要最小限にする
- 信頼できない共用端末で重要アカウントへログインしない
- 端末へ推測されにくい画面ロックを設定する
- 多要素認証やパスキーを有効にする
- ログイン中の端末やセッションを定期的に確認する
- メッセージ内のリンクから安易にログインしない
シークレットモードはCookieや履歴を残しにくくする点では役立ちますが、利用中のマルウェアや画面監視を防ぐものではありません。
乗っ取りの兆候
- 身に覚えのないログイン端末やセッション
- 知らない場所や時間のアクセス履歴
- 未読メールが既読になっている
- 覚えのない送信、ダウンロード、削除
- 復旧先、転送、共有設定の変更
- 知らない認証方法やパスキーの追加
盗まれた既存セッションは、新しいログインとして検知されない場合があります。通知だけでなく、端末・セッション一覧や操作履歴も確認します。
疑わしいときの対応
- 信頼できる別の端末を使う
- すべての端末・セッションからログアウトする
- 固有の新しいパスワードへ変更する
- 多要素認証、パスキー、復旧先を確認する
- 知らない端末・アプリ連携・拡張機能を削除する
- OSとアプリを更新し、マルウェアの可能性を調べる
- 転送、共有、削除、決済などの履歴を確認する
- 必要に応じてサービスのサポートへ連絡する
メールアカウントは他サービスのパスワード再設定にも使われるため、優先して保護します。
SECRET CLOUD
暗号化とセッション保護は別の防御
シークレットクラウドではGoogleログインとSupabase Authを利用してアプリのセッションを管理します。利用者側でも端末の画面ロックを有効にし、OSとアプリを更新し、不審なアプリを入れないことが重要です。侵害が疑われる場合はGoogleアカウントの端末やセッションも確認してください。
プライバシーと安全管理を見るまとめ
セッションハイジャックは、ログイン済み状態を示す有効なセッションを悪用し、本人になりすます攻撃です。攻撃者がパスワードを知らなくても成立する場合があります。
多要素認証やパスキーに加えて、端末、アプリ、ブラウザ、拡張機能、セッション終了まで守りましょう。異常が疑われるときは、パスワード変更だけでなく、全セッション終了と端末の確認も必要です。
参考情報
- OWASP「Session Management Cheat Sheet」
- OWASP「Cookie Theft Mitigation Cheat Sheet」
- MDN Web Docs「Secure cookie configuration」
攻撃手法やセッション管理機能は更新されます。利用中のサービスの最新情報も確認してください。