セッションハイジャックとは？仕組み・被害例・対策をわかりやすく解説

「ログインしたはずの自分のアカウントが、知らないうちに誰かに操作されていた」「購入した覚えのない商品の注文確認メールが届いた」――こうした被害の裏側に潜んでいることが多いのが、セッションハイジャックと呼ばれる攻撃です。

セッションハイジャックは、Webアプリケーションのセッション管理の隙を突いてユーザーになりすます手法で、IPA（情報処理推進機構）の安全なWebサイトの作り方でも主要な脅威として取り上げられています。パスワードを盗まなくても「ログイン済みの状態」をそのまま乗っ取れるため、被害に気づきにくいのが厄介なところです。

この記事では、セッションハイジャックの仕組み・代表的な攻撃パターン・現場で実践できる防御策を、現場目線でわかりやすく解説します。

セッションハイジャックとは？なぜ今でも被害が絶えないのか

セッションハイジャックとは、Webサービスで使われるセッションID（ログイン状態を保持するための識別子）を第三者が不正に取得・利用し、正規ユーザーになりすます攻撃です。

Webアプリケーションは、ユーザーがログインするとセッションIDを発行し、以降のリクエストではこのIDを使って「誰からのリクエストか」を判別しています。つまり、セッションIDはログインの「合い鍵」のようなもので、これを手に入れた攻撃者は、パスワードを知らなくてもログイン済みユーザーとしてシステムを操作できてしまいます。

セッションハイジャックが今でも被害を生み続ける理由は主に3つあります。

・パスワードが不要: セッションIDさえ手に入れれば認証をすり抜けられるため、パスワードの強度やMFA（多要素認証）だけでは防ぎきれない
・正規ユーザーと区別できない: サーバーから見ると、盗まれたセッションIDによるアクセスと正規ユーザーのアクセスは見分けがつかない
・セッション管理の甘いシステムが多い: セッションIDの生成方法やCookie設定が不適切なWebアプリケーションは、いまだに少なくない

攻撃の仕組み ― セッションIDはどう盗まれるのか

セッションハイジャックには、大きく分けて3つの攻撃パターンがあります。それぞれの仕組みを「防御のために知る」目的で解説します。

1. セッションIDの盗聴（ネットワーク経由）

通信が暗号化されていない環境（HTTP通信や、暗号化されていない公衆Wi-Fiなど）では、ネットワーク上を流れるデータを傍受することで、セッションIDを含むCookieを盗み取ることが可能です。

たとえば、カフェの無料Wi-FiでHTTP接続のサイトにログインしている場合、同じネットワークにいる攻撃者がパケットキャプチャ（通信データの記録）を行えば、セッションIDは平文のまま読み取られてしまいます。HTTPS化が当たり前になった現在でも、混在コンテンツ（一部がHTTPのまま）のサイトや、Cookie属性の設定ミスがある場合にこのリスクは残ります。

2. XSS（クロスサイトスクリプティング）経由での窃取

Webアプリケーションに XSS の脆弱性がある場合、攻撃者が仕込んだスクリプトによって、ブラウザに保存されているセッションCookieの値を外部に送信させることができます。

この攻撃が成立する条件は「WebアプリケーションにXSSの脆弱性が存在すること」と「CookieにHttpOnly属性が設定されていないこと」の2つです。逆に言えば、XSS対策とHttpOnly属性の設定という2重の防御を行えば、この攻撃パターンは成立しにくくなります。

3. セッション固定攻撃（Session Fixation）

セッション固定攻撃は、セッションIDを「盗む」のではなく「あらかじめ仕込む」手法です。攻撃者が事前に取得したセッションIDをユーザーに使わせ、ユーザーがそのIDでログインした後に、同じIDでアクセスしてなりすまします。

具体的には、攻撃者が用意したセッションIDを含むURLやフォームをユーザーに踏ませ、ユーザーがログイン操作を行うと、そのセッションIDが認証済み状態になります。攻撃者は最初から同じIDを知っているため、以降は正規ユーザーとしてアクセスできるようになります。

この攻撃は「ログイン成功時にセッションIDを再生成する」という対策だけで防げるにもかかわらず、この処理が欠けているシステムは意外と多く存在します。

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

セッションハイジャックが成功すると、攻撃者はログイン済みユーザーと同じ権限でシステムを操作できます。

特に管理者権限のセッションが奪われた場合、影響範囲は一気に拡大します。管理画面から全ユーザーの個人情報にアクセスできるケースや、システム設定を変更されてバックドア（裏口）を仕掛けられるケースもあるため、管理者アカウントのセッション管理は一般ユーザー以上に厳格に行う必要があります。

具体的な防御手順

セッションハイジャックの防御は「セッションIDを盗まれない」「盗まれても使えない」の2つの観点で対策を積み重ねることが重要です。

1. HTTPS通信を徹底する

すべてのページをHTTPS化し、CookieにSecure属性を設定します。Secure属性が付いたCookieはHTTPS通信でのみ送信されるため、ネットワーク上での盗聴によるセッションID漏洩を防げます。

# Apache: Cookieへのセキュリティ属性の一括設定
# httpd.confまたは.htaccessに追記
Header always edit Set-Cookie (.*) "$1; Secure; HttpOnly; SameSite=Lax"

# Nginx: セッションCookieのセキュリティ強化
# proxy_cookie_pathディレクティブで属性を追加
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

HTTPからHTTPSへのリダイレクト設定も忘れずに行いましょう。リダイレクト前の最初の1リクエストがHTTPで送信されるリスクを防ぐには、HSTS（HTTP Strict Transport Security）ヘッダーの設定も有効です。

2. Cookie属性を正しく設定する

セッションCookieには以下の3つの属性を必ず設定します。

・HttpOnly: JavaScriptからCookieにアクセスできなくする。XSS経由でのセッションID窃取を防ぐ
・Secure: HTTPS通信でのみCookieを送信する。平文通信での漏洩を防ぐ
・SameSite: 異なるサイトからのリクエストにCookieを付与するかを制御する。CSRF対策にも有効

# PHPの場合: php.iniでのセッションCookie設定
session.cookie_secure = On
session.cookie_httponly = On
session.cookie_samesite = Lax

# Pythonの場合: Flaskでの設定例
# app.config['SESSION_COOKIE_SECURE'] = True
# app.config['SESSION_COOKIE_HTTPONLY'] = True
# app.config['SESSION_COOKIE_SAMESITE'] = 'Lax'

3. ログイン時にセッションIDを再生成する

ユーザーがログインに成功した時点で、新しいセッションIDを発行し直します。これにより、セッション固定攻撃で事前に仕込まれたセッションIDを無効化できます。

# PHPでのセッションID再生成
# session_regenerate_id(true);
# 引数trueで古いセッションデータを削除

# Java Servletでのセッション再生成
# request.getSession().invalidate();
# HttpSession newSession = request.getSession(true);

この処理はログイン成功直後だけでなく、権限レベルが変わるタイミング（一般ユーザー→管理者への切り替え等）にも適用することが推奨されます。

4. セッションの有効期限とアイドルタイムアウトを設定する

セッションの最大有効期限（絶対タイムアウト）と、操作がない場合の自動切断（アイドルタイムアウト）の両方を設定します。

# PHPの場合: セッション有効期限の設定
# アイドルタイムアウト: 30分（1800秒）
session.gc_maxlifetime = 1800

# 絶対タイムアウトはアプリケーション側で実装
# $_SESSION['last_activity'] に最終操作時刻を記録し
# 一定時間経過後にセッションを破棄する

セッションの有効時間が長いほど、盗まれたセッションIDが悪用される時間的余裕を攻撃者に与えてしまいます。業務システムなら30分～1時間、金融系なら15分程度が目安です。

5. セッションIDの生成に暗号論的乱数を使う

セッションIDが推測可能な文字列（連番、タイムスタンプ、ユーザーIDのハッシュなど）で生成されている場合、攻撃者がIDを総当たりで推測するブルートフォース攻撃が成立する恐れがあります。

主要なプログラミング言語やフレームワークが提供する標準のセッション管理機能は、暗号論的に安全な乱数生成器を使用しています。自前でセッション管理を実装するのではなく、フレームワークの標準機能を使うことが最も確実です。

中小企業でも今日からできること

「自社でWebアプリケーションを開発していないから関係ない」と思うかもしれませんが、WordPressなどのCMSやSaaS型の業務システムを使っているなら、セッション管理のリスクは他人事ではありません。

特に効果が高いのは「管理画面のアクセス制限」です。WordPressであれば /wp-admin/ へのアクセスを社内ネットワークやVPN経由に限定するだけで、たとえセッションIDが漏洩しても管理画面への不正アクセスを大幅に防げます。

よくある誤解と注意点

【注意】「HTTPS化しているから安全」ではない

HTTPS化はセッションIDの盗聴を防ぐために必須ですが、それだけではセッションハイジャックの全パターンを防げません。XSS経由でのCookie窃取やセッション固定攻撃はHTTPS環境でも成立します。HTTPS化はあくまで対策の一つであり、Cookie属性の設定、セッションID再生成、XSS対策など、複数の防御策を組み合わせる必要があります。

【注意】「セッションIDをURLに含める」のは危険

古いWebアプリケーションでは、Cookieが使えないブラウザ向けにセッションIDをURLのパラメータに含める実装が見られます。この方式では、URLがブラウザの履歴やRefererヘッダーを通じて外部に漏洩する恐れがあります。セッションIDは必ずCookieで管理し、URLには含めない設計にしましょう。

【注意】「ログアウト機能がなくても問題ない」は危険な思い込み

「ブラウザを閉じればセッションは切れるだろう」と考えてログアウト機能を軽視するケースがありますが、サーバー側のセッションはブラウザを閉じても残っている場合があります。明示的なログアウト機能を実装し、ログアウト時にはサーバー側のセッションデータを確実に破棄する処理が必要です。共用PCや公共端末でのリスクを考えると、ログアウト機能は必須です。

本記事のまとめ

セッションハイジャックは、ユーザーのログイン状態を保持するセッションIDを不正に取得・利用し、正規ユーザーになりすます攻撃です。パスワードを盗まなくても成立するため、認証の強化だけでは防ぎきれない点が厄介です。

防御の基本は「セッションIDを盗まれない環境を作る」ことと「盗まれても被害を最小化する」ことの二段構えです。HTTPS化、Cookie属性の適切な設定、ログイン時のセッションID再生成、有効期限の設定を組み合わせることで、実効性のある防御を構築できます。

Webサーバー（ApacheやNginx）でのHTTPS設定やCookieセキュリティ属性の追加方法については、姉妹サイトLinuxMaster.JPで詳しく解説しています。サーバー設定とアプリケーション対策の両面から対策を進めましょう。