ネットワーク攻撃

セッションハイジャックせっしょんはいじゃっく

セッションIDクッキーなりすましXSS中間者攻撃認証

セッションハイジャックについて教えて

簡単に言うとこんな感じ！

ログイン済みの「入館証」を盗まれて、悪者が「あなたのふり」をしてサービスを使い放題にされる攻撃だよ！パスワードを盗まなくても、ログイン後に発行される「通行手形（セッションID）」を横取りするだけで乗っ取れちゃうんだ。

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

Webサービスにログインすると、サーバーは「この人はさっき認証済みです」という印としてセッションID（一時的な識別トークン）を発行し、ブラウザのCookieなどに保存します。以降のリクエストではパスワードの代わりにこのIDを提示するだけでOKという仕組みです。セッションハイジャックとは、攻撃者がこのセッションIDを不正に入手し、正規ユーザーになりすましてサービスを操作する攻撃手法です。

パスワードそのものは盗まなくてよいため、多要素認証（MFA）が導入されていても突破されうる点が厄介です。ログインに成功した「後」の状態を乗っ取るので、認証後の信頼を丸ごと奪う攻撃と言えます。ECサイトでの不正購入、ネットバンキングの不正送金、企業の業務システムへの不正アクセスなど、実害が直結しやすい危険な攻撃です。

セッションIDはなぜ狙われるのか

WebアプリはHTTPというプロトコルを使いますが、HTTPは「状態を持たない（ステートレス）」設計です。つまり、リクエストをするたびに「誰からのリクエストか」をサーバーが忘れてしまいます。そこで便宜上、ログイン時にセッションIDという「通し番号」を発行し、それをやりとりすることでログイン状態を維持しています。このIDさえあれば誰でもその利用者として行動できるため、攻撃者の格好の標的になります。

主な攻撃手法

手法	概要	典型的な経路
盗聴（パケットスニッフィング）	暗号化されていない通信からセッションIDを読み取る	公衆Wi-Fiなど
XSS（クロスサイトスクリプティング）	悪意のあるJavaScriptをサイトに埋め込み、訪問者のCookieを窃取	掲示板・フォーム等
セッション固定攻撃	攻撃者があらかじめ設定したIDを被害者に使わせる	フィッシングURL等
中間者攻撃（MITM）	通信経路に割り込みセッションIDを傍受・改ざん	ARP spoofing等
クロスサイトリクエストフォージェリ（CSRF）	ログイン済みユーザーに意図しないリクエストを送信させる	罠サイト等
マルウェア	端末に侵入しCookieファイルを直接盗み出す	メール添付・偽アプリ等

攻撃の流れを一言で覚えるなら

「ID盗んで、なりすます」 ── 盗取・偽装の2ステップ

セッションIDを「盗む」フェーズと、それを「使う」フェーズに分けて理解すると整理しやすいです。

セッションIDの安全性を左右するポイント

チェック項目	安全	危険
長さ・ランダム性	128ビット以上のランダム値	連番・短い値
有効期限	短時間・操作後に延長	無期限・長期間
送信経路	HTTPS（暗号化）	HTTP（平文）
Cookie属性	`HttpOnly` + `Secure` + `SameSite`	属性なし
ログイン後の再発行	認証成功時に新規発行	認証前後で同一ID

歴史と背景

1990年代後半 — Webアプリが急増し、セッション管理の必要性が認識される。初期の実装はIDが推測しやすく、セッション固定・盗聴が横行
2000年代前半 — XSSとCSRFが相次いで悪用され、OWASPがTop 10脆弱性として警告を発し始める
2003年 — RFC 2965（Cookie仕様強化）が公開。Secure属性などが整備されるが、普及は緩慢
2008年 — FireSheepなどのツールが登場し、公衆Wi-FiでのセッションID盗聴の容易さが一般に知られる
2011年ごろ — HTTPSの普及促進が本格化し、主要SNSが常時SSL化へ移行。盗聴リスクが大幅に低下
2016年 — SameSite Cookie属性がChrome 51で実装され、CSRF経由のセッション悪用に対する防御が標準化へ
現在 — ゼロトラスト設計・短命トークン（JWT）・継続的な認証（リスクベース認証）など、セッション依存を減らす方向に進化中

攻撃経路と防御の対応関係

発注者・管理者が押さえるべき対策チェックリスト

システムを発注・導入する際に、以下の点をベンダーに確認しましょう。

【セッションハイジャック対策チェックリスト】

通信の暗号化
  □ サイト全体がHTTPS（TLS 1.2以上）で保護されているか
  □ HSTSが設定されているか（HTTP→HTTPSの強制リダイレクト）

Cookie設定
  □ HttpOnly属性 — JavaScriptからCookieを読み取れなくする
  □ Secure属性   — HTTPS通信時のみCookieを送信
  □ SameSite属性 — 外部サイトからのリクエストにCookieを付けない

セッション管理
  □ ログイン成功後にセッションIDを再生成しているか
  □ セッションの有効期限（タイムアウト）が設定されているか
  □ ログアウト時にサーバー側でセッションを無効化しているか

入力・出力処理
  □ XSS対策（入力値のサニタイズ・エスケープ）が実施されているか
  □ CSRFトークンが実装されているか

監視・検知
  □ 同一セッションで異常なIPアドレス変更を検知する仕組みがあるか
  □ 不審なセッションを強制終了できる管理機能があるか

規格・RFC番号	内容
RFC 6265	HTTP State Management Mechanism（Cookie仕様。`HttpOnly`・`Secure`属性を定義）
RFC 6265bis	`SameSite`属性など現代のCookie拡張仕様（策定中）
RFC 7230	HTTP/1.1メッセージ構文（ステートレスプロトコルの仕様）
RFC 6797	HTTP Strict Transport Security（HSTS）。HTTPSを強制し盗聴リスクを低減