IT用語集 2023/10/20

セッションハイジャックとは？わかりやすく10分で解説

コラム

はじめに

セッションハイジャックは、ログイン後に発行されたセッションIDや同等のトークンを攻撃者が再利用し、本人として操作する攻撃です。パスワードが漏れていなくても成立し、中間者攻撃、クロスサイトスクリプティング、端末侵害、実装不備など複数の経路で起こります。対策はHTTPSだけで終わらず、Cookie設定、セッションIDの再発行、失効設計、重要操作前の再認証まで含めて組み立てます。

攻撃の成立条件を整理すると、論点は二つに分かれます。ひとつは識別子を盗まれないようにすること、もうひとつは盗まれた後でも被害範囲を狭めることです。前者だけでは足りず、後者まで設計に入っているかで被害規模が変わります。

セッションハイジャックとは

Webアプリケーションは、HTTPが状態を保持しない前提で動くため、ログイン後の利用者を識別する情報としてセッションIDやトークンを使います。攻撃者がその値を入手してサーバーに提示すると、サーバー側が攻撃者を正規ユーザーとして扱うことがあります。これがセッションハイジャックの基本構造です。

セッションIDの役割

セッションIDは、ログイン状態や権限、画面遷移にひもづく状態を参照する識別子です。識別子そのものに機密情報を入れるのではなく、意味づけはサーバー側に保持します。ブラウザでは多くの場合、Cookieを通じて送受信されます。

混同しやすい攻撃との違い

資格情報の窃取：IDやパスワードそのものを盗み、新規ログインから始める攻撃です。
セッションハイジャック：ログイン後の識別子を再利用し、本人として操作する攻撃です。パスワードが分からなくても成立します。
セッションフィクセーション：攻撃者が先に用意した識別子を被害者に使わせる攻撃です。成立の起点がログイン前にあります。

特にセッションフィクセーションは、同じ「セッション」を悪用する攻撃でも、既に成立したセッションを奪う手口とは異なります。ログイン成功時にセッションIDを再発行するかどうかが、両者を分ける重要な実装ポイントになります。

セッションハイジャックの主な原因

セッションハイジャックは、多くの場合、セッションIDまたは同等のトークンの不正取得で成立します。実際の原因は「推測される」「盗まれる」「固定される」の三つに整理できます。

推測しやすいセッションID

セッションIDが短い、規則性がある、乱数品質が低いといった実装では、総当たりや推測の余地が残ります。独自実装や古い仕組みではこの問題が出やすく、フレームワーク標準のセッション管理を外している箇所は見直し対象になります。

セッションIDの奪取

セッションIDが盗まれる経路は一つではありません。代表例は次のとおりです。

中間者攻撃や盗聴：HTTPSが徹底されていない通信や改ざんされた経路で識別子が抜き取られます。
クロスサイトスクリプティング：悪意あるスクリプトがブラウザ内の情報に触れ、Cookieなどを外部へ送ります。
端末側の侵害：マルウェアや不審な拡張機能がブラウザ情報を窃取します。
URL経由の漏えい：識別子をURLに含める実装では、アクセスログ、履歴、ブックマーク、Referer、画面共有に露出しやすくなります。

セッション固定化によるなりすまし

セッションフィクセーションでは、攻撃者が知っているセッションIDを被害者に使わせ、被害者のログイン後にそのIDを再利用します。ログイン成功時にセッションIDを再発行しない実装で起こりやすい問題です。

セッションハイジャックで起こる被害

攻撃者は本人として扱われるため、個人情報の閲覧や設定変更、投稿、購入、ポイント利用、メールアドレス変更などを実行できます。特に回復手段まで書き換えられる設計では、被害が長引きます。

一般ユーザーに出る影響

オンラインショッピングやSNSのアカウントが乗っ取られると、保存済みの配送先や連絡先、注文履歴、ポイント残高、投稿権限などが悪用されます。被害は金銭面だけに限らず、なりすまし投稿や連絡先への詐欺拡散にもつながります。

サービス提供側に出る影響

運営側では、不正取引対応、アカウント復旧、問い合わせ増加、ブランド毀損、監査対応などの負担が発生します。複数アカウントで同時に起きた場合は、セキュリティ事故として公表判断まで含めた対応が必要になることがあります。

サービス提供側が優先して確認する対策

セッションIDの発行方法と受け取り方法を見直す

セッションIDは、十分な長さと予測しにくい乱数品質を備えた値にします。独自方式を足すより、実績のあるフレームワーク標準のセッション管理を使う方が安全です。加えて、セッションIDをURLパラメータで受け取らず、Cookieでやり取りする構成にそろえると、固定化や漏えいのリスクを抑えやすくなります。

Cookie属性と有効期限を詰める

識別子をCookieで扱う場合は、属性設定で露出経路を減らします。最低限の確認項目は次のとおりです。

通信全体をHTTPSで統一し、CookieにSecure属性を付与する
JavaScriptから読む理由がないCookieにHttpOnly属性を付与する
クロスサイト送信を制限するため、用途に応じてSameSite属性を設定する
アイドルタイムアウトと絶対有効期限をサーバー側で管理する
ログアウト時にクライアント側とサーバー側の両方でセッションを失効させる

SameSiteはCSRFの発生条件を狭める設定であり、セッションIDそのものの窃取を直接止める設定ではありません。SecureやHttpOnly、XSS対策、失効設計と組み合わせて初めて意味を持ちます。

ログイン直後と重要操作前の制御を分ける

ログイン成功時、権限変更時、パスワード変更時にはセッションIDを再発行します。さらに、決済、送付先変更、メールアドレス変更、二要素認証や多要素認証の設定変更といった重要操作では、パスワード再入力や追加認証を求める設計にすると、セッションが奪われた後の被害範囲を絞れます。

XSS対策と監視を切り離さない

クロスサイトスクリプティングへの対処が弱いと、HTTPSとCookie属性だけでは守りきれません。出力時のエスケープ、危険な入力の無害化、CSPの適用、ログ監視、不自然なIPやUser-Agentの変化の検知を並行して進めます。WAFは補助的に使えますが、セッション管理の実装不備そのものは置き換えません。

利用者側でできる対策

利用者側だけで攻撃を完全に止めることはできませんが、被害の入口を狭める行動はあります。

OS、ブラウザ、拡張機能を更新し、不審な拡張機能を削除する
公共Wi-Fiや不審なネットワークでは、機微な操作を避ける
フィッシング詐欺や不審なリンクからログインしない
ログイン通知や履歴確認を有効にし、異常があれば全端末からログアウトする
メールアドレスや認証設定に身に覚えのない変更がないか確認する

まとめ

セッションハイジャックは、ログイン後の識別子が奪われた時点で成立し得る攻撃です。防御の軸は、識別子を盗ませない設計と、盗まれても被害を広げない制御の二つです。WebサービスではCookie属性、HTTPS、セッションID再発行、サーバー側失効、重要操作の再認証を組み合わせ、利用者側では端末管理と不審な通信経路の回避を徹底します。