セッションハイジャックとは？仕組み・盗まれる手口と対策を図解
ニュースやセキュリティの解説で「セッションハイジャック」という言葉を見かけて、何が乗っ取られるのか気になっていませんか。
ひとことで言えば、ログインしたあとの「ログイン済みのしるし」を盗まれ、パスワードを知らない相手に本人として使われてしまう攻撃です。
この記事では、仕組みと盗まれる手口、利用者とサイト運営者それぞれの対策までを図で解説します。
この記事は以下のような人におすすめ！
- セッションハイジャックの意味と、不正ログインとの違いを知りたい人
- 公衆Wi-Fiや偽サイトで何が盗まれるのか、具体的に知りたい人
- 自分のアカウントやWebサイトを守る対策を確かめたい人
本記事はプロモーション（アフィリエイト広告）を含みます。
セッションハイジャックとは何か
1-1. セッションハイジャックは「ログイン状態」の乗っ取り
セッションハイジャックは、直訳すると「セッションの乗っ取り」です。
ここでいうセッションとは、Webサイトにログインしてから、ログアウトするかしばらく操作しなくなるまでの、ひと続きのやり取りのことです。
IPA（情報処理推進機構）の「安全なウェブサイトの作り方」は、セッションIDの発行や管理に不備があると、ログイン中の利用者のIDを不正に手に入れられ、その人になりすましてアクセスされるおそれがあると説明しています。
この問題を悪用した攻撃が、セッションハイジャックです（参考5）。
図の上の段のように、本人がパスワードでログインすると、サイトは「ログイン済みのしるし」としてセッションIDを渡します。
攻撃者がこのIDを手に入れて自分のブラウザで使うと、サイトからは本人と見分けがつきにくくなります。
その結果、攻撃者はパスワードを知らなくても、本人のアカウントで買い物をしたり、メッセージを読んだり、設定を変えたりできてしまうおそれがあります。
銀行の窓口でたとえるなら、本人確認をすませたあとに受け取った番号札を、横から抜き取られて先に呼ばれてしまうようなイメージです。
窓口は番号札を持っている人を本人として扱うので、札そのものを守ることが大切になります。
セッションハイジャックで守るべきものも、この番号札にあたるセッションIDです。
この記事では、もっとも身近なWebサイトのログインを例に説明します。
1-2. セッションIDとCookieのしくみ
そもそも、なぜ「ログイン済みのしるし」が必要なのでしょうか。
Webの通信で使われるHTTPは、1回ごとのやり取りが独立していて、前のやり取りを覚えていない仕組みです。
そのため、何も工夫をしなければ、ページを移動するたびにパスワードを入れ直さなければなりません。
そこで多くのサイトは、ログインに成功した利用者にセッションIDという長い文字列を渡し、ブラウザにCookie（クッキー）として保存してもらいます。
Cookieは、サイトがブラウザに保存させる小さなデータで、ブラウザは同じサイトへ次に通信するとき、それを自動で送り返します（参考2）。
図の③のように、ブラウザはページを開くたびにセッションIDを添えて送ります。
サイトは届いたIDを手元の記録と照らし合わせ、「さっきログインした人だ」と判断して、その人向けのページを返します。
ネットショップでカートの中身が消えなかったり、ページを移ってもログインしたままだったりするのは、この仕組みのおかげです。
裏を返すと、ログインしたあとのサイトは、パスワードではなくセッションIDを見て相手を見分けているということです。
Webの安全性に取り組む国際的なコミュニティのOWASPも、ログインのあとのセッションIDは、そのサイトが使うもっとも強い認証と一時的に同じ重みを持つため、知られるとパスワードがなくても本人になりすまされると説明しています（参考1）。
なお、セッションIDの受け渡しにはCookie以外の方法もありますが、この記事ではもっとも一般的なCookieを例に説明します。
1-3. パスワードの盗用との違いと、起こりうる被害
「アカウントの乗っ取り」と聞くと、パスワードを盗まれることを思い浮かべる人が多いかもしれません。
パスワードの盗用はログイン画面を通って入る攻撃で、セッションハイジャックはログインがすんだあとのしるしを使って入る攻撃です。
この違いが大きく効いてくるのが、多要素認証を使っている場合です。
多要素認証は、パスワードに加えてスマートフォンでの確認などを求める仕組みで、パスワードだけを盗まれても、図の上の段のように入口で止めやすくなります。
一方で、セッションIDはログインと認証がすんだあとに渡されるものなので、盗まれると入口の確認を通らずに使われてしまいます。
攻撃の手口を整理したMITRE ATT&CKも、盗んだセッションのCookieを使うと、セッションがすでに認証ずみのため、一部の多要素認証を回避できると説明しています（参考4）。
起こりうる被害は、乗っ取られたアカウントで本人ができることとほぼ同じです。
| サービスの種類 | 起こりうる被害の例 |
|---|---|
| ネットショップ | 登録したカードでの買い物、配送先の書き換え |
| SNS・メール | メッセージの盗み見、本人になりすました投稿や送信 |
| 会社のクラウドサービス | 社内の文書やメールの持ち出し、設定の変更 |
被害の範囲は、そのセッションで何ができるかによって変わります。
また、攻撃者がセッションを使っている間も、本人はふだんどおりサービスを使えていることがあり、気づくのが遅れやすい点もやっかいです。
サイトによっては、大事な操作の前にパスワードの入力をもう一度求めるので、そうした仕組みがあると被害を抑えやすくなります。
- セッションハイジャックは、ログイン済みのしるし（セッションID）を盗んで本人になりすます攻撃
- サイトはログインのあと、パスワードではなくセッションIDで相手を見分けている
- 盗まれたIDは、多要素認証の確認を通らずに使われることがある
セッションIDが盗まれる主な手口
ここからは、セッションIDがどのように盗まれるのかを、代表的な4つの手口に分けて見ていきます。
2-1. 暗号化されていない通信を盗み見られる
OWASPは、セッションIDが漏れたり、途中で盗み取られたり、推測や固定化をされたりすると、セッションハイジャックにつながると説明しています（参考1）。
その中で、まず知っておきたいのが通信の盗み見です。
セッションIDは、ページを開くたびにブラウザからサイトへ送られます。
その通信が暗号化されていないと、同じネットワークにいる第三者が、通信の中身ごとIDを読み取れてしまうおそれがあります。
図の上の段は、暗号化されていない「http://」の通信です。
公衆Wi-Fiのように、だれでも接続できるネットワークでは、図のように利用者とWi-Fiの間の通信を、近くにいる攻撃者にのぞき見られることも考えられます。
下の段の「https://」では、通信が暗号化されているので、途中で見られても中身は読めません。
MDNによると、CookieにSecure属性を付けると、そのCookieは暗号化されたHTTPSの通信でしか送られなくなります（参考2）。
今では多くのサイトがHTTPSに対応していますが、ログインの前にアドレス欄が「https://」で始まっているかを確かめる習慣は、今も役に立ちます。
偽のWi-Fiに接続させて、通信の途中に割り込む手口もあるので、提供元のわからないWi-Fiには、なるべくつながないようにしましょう。
通信の途中に割り込む攻撃は、記事の最後で紹介する中間者攻撃の記事でくわしく解説しています。
2-2. クロスサイトスクリプティング（XSS）で抜き取られる
2つ目は、サイトの弱点を突いて、利用者のブラウザから直接Cookieを抜き取る手口です。
代表的なのが、クロスサイトスクリプティング（XSS）と呼ばれる攻撃です。
XSSは、サイトの弱点を利用して、攻撃者が用意したスクリプトをほかの利用者のブラウザで動かす攻撃です。
スクリプトとは、ブラウザの上で動く小さなプログラムのことです。
XSSには、仕込んだスクリプトがサイトに保存されるものや、罠のリンクを開いたときだけ動くものなど、いくつかの種類があります。
図のように、攻撃者はまず、弱点のあるサイトに不正なスクリプトを仕込みます。
利用者がそのページを開くと、スクリプトがページと一緒に届き、利用者のブラウザで動き出します。
スクリプトはページの一部として動くため、何も対策がないと、そのサイトのCookieを読み取って攻撃者へ送れてしまいます。
MDNは、HttpOnly属性を付けたCookieはJavaScriptから読み取れなくなり、XSSの被害を減らす助けになると説明しています（参考2）。
弱点はサイトの側にあるので、利用者だけで完全に防ぐのは難しく、サイトの運営者が弱点をなくすことが基本になります。
XSSの仕組みや種類は、記事の最後で紹介するクロスサイトスクリプティングの記事にまとめています。
2-3. IDの推測と「セッションIDの固定化」
3つ目は、IDを盗むのではなく、当てたり、あらかじめ決めておいたりする手口です。
セッションIDが連番や日時のように規則的だと、攻撃者はほかの人のIDを推測できてしまいます。
そのため、セッションIDは推測しにくい、ランダムで十分に長い値にする必要があります。
もう1つが、セッションIDの固定化（セッションフィクセーション）と呼ばれる手口です。
図の①のように、攻撃者はまずサイトにアクセスして、ログイン前のセッションIDを1つ手に入れます。
次に、罠のリンクなどを使って、利用者にそのIDのままサイトを使わせます。
利用者がそのIDのままログインすると、攻撃者は自分が知っているIDで、ログイン済みの状態に入れてしまいます。
IPAの「安全なウェブサイトの作り方」は、こうした攻撃への根本的な対策として、セッションIDを推測が難しいものにすることや、ログインに成功したあとに新しくセッションを始めることを挙げています（参考5）。
ログインのたびにIDが新しくなれば、攻撃者が前もって用意したIDは使えなくなります。
推測されにくいIDにするだけでは固定化の手口は防げないので、2つの対策はセットで考えます。
利用者の立場では、メールやメッセージで届いた見知らぬリンクからログインしないことが、この手口への備えになります。
2-4. マルウェアや偽サイトでCookieごと盗まれる
4つ目は、利用者のパソコンや、ログインの通り道そのものを狙う手口です。
MITRE ATT&CKは、Webのセッションを盗む方法として、パソコンの中からCookieを抜き取る方法と、偽のサイトでログインを中継する方法を取り上げています。
図の左は、パソコンに入り込んだマルウェアが、ブラウザに保存されたCookieを抜き取る手口です。
Cookieはパソコンの中のファイルやブラウザのメモリ、通信の中にあり、それを狙うマルウェアの例が複数あるとされています。
図の右は、本物そっくりの偽サイトが、利用者と本物のサイトの間でログインのやり取りを中継する手口です。
利用者が偽サイトでIDやパスワード、多要素認証のコードを入力すると、偽サイトはそれを本物のサイトへそのまま渡し、発行されたセッションのCookieを横取りします。
MITRE ATT&CKでも、攻撃者が用意した中継のサーバーでセッションのCookieを集める仕組みがあり、フィッシングに使われうると説明されています（参考3）。
この手口では、本人が正しい手順で多要素認証まで終えていても、その結果のしるしを奪われてしまいます。
「認証のコードを入れたから安心」とは言い切れないので、ログインはブックマークや公式アプリから始めるようにしましょう。
ここまでの4つの手口を、表にまとめておきます。
| 手口 | IDが盗まれる場所 | 主な対策 |
|---|---|---|
| 通信の盗み見 | 暗号化されていない通信 | HTTPS、Secure属性 |
| XSS | 利用者のブラウザ | サイトの弱点の修正、HttpOnly属性 |
| 推測・固定化 | サイトのIDの作り方 | ランダムなID、ログイン時の作り直し |
| マルウェア・偽サイト | 利用者のパソコン、偽のログイン画面 | 端末の保護、正しい入口からのログイン |
利用者ができるセッションハイジャック対策
3-1. HTTPSのサイトでログインし、Wi-Fiを選ぶ
利用者がまずできるのは、セッションIDが流れる通り道を安全に保つことです。
ログインするときは、アドレス欄が「https://」で始まり、ブラウザに警告が出ていないかを確かめましょう。
証明書のエラーなどの警告が出たときは、そのままログインせず、いったんページを閉じるのが安全です。
公衆Wi-Fiを使うときは、お店や施設が案内している正しいネットワーク名かどうかを確かめてから接続しましょう。
提供元がわからないWi-Fiや、パスワードなしでだれでもつながるWi-Fiでは、大事なアカウントへのログインを控えるのが無難です。
外出先でどうしてもログインが必要なときは、スマートフォンのモバイル回線に切り替えるのも1つの方法です。
| 場面 | 気をつけること |
|---|---|
| 自宅のWi-Fi | ルーターにパスワードを設定し、知らない機器をつながない |
| 公衆Wi-Fi | 正しいネットワーク名か確かめ、大事なログインは控える |
| 警告が出たサイト | そのままログインせず、ページを閉じる |
2章で見たように、HTTPSでも防げない手口はあるので、ここでの対策は「通り道での盗み見を減らすもの」と考えてください。
3-2. 使い終わったらログアウトし、端末を守る
2つ目は、盗まれたIDが使える時間を短くし、そもそも盗まれにくい端末を保つことです。
共用のパソコンや、ほかの人も触る端末でログインしたときは、使い終わったら必ずログアウトしましょう。
OWASPは、サイトの作り手に対して、ログアウトのボタンを用意し、ログアウトしたらサーバー側でセッションを無効にするよう求めています（参考1）。
サイトがこのように作られていれば、ログアウトしたあとは、そのIDが盗まれていても使えなくなります。
「ログインしたままにする」の選択は、自分だけが使う端末に限ると安心です。
MITRE ATT&CKも、セッションのCookieは、サイトを使っていない間も長く有効なままのことが多いと指摘しています（参考3）。
また、OSやブラウザを最新の状態に保ち、ウイルス対策ソフトを動かしておくことも、Cookieを盗むマルウェアへの備えになります。
出どころのわからないソフトや、メールに添付された見覚えのないファイルは、開かないようにしましょう。
ブラウザの拡張機能も、信頼できる提供元のものだけを、必要な数にしぼって使うと安心です。
3-3. 乗っ取りに気づいたら「すべての端末からログアウト」
身に覚えのないログインの通知や、送った覚えのないメッセージに気づいたら、乗っ取りを疑って早めに動きましょう。
作業は、乗っ取りの原因かもしれない端末ではなく、安全だとわかっている別の端末で行うと安心です。
図の順番のポイントは、まずすべての端末からログアウトし、続けてすぐにパスワードを変えることです。
セッションハイジャックで盗まれたのはログイン済みのしるしなので、パスワードより先に、そのしるしを使えなくする必要があるからです。
サービスによっては、設定画面に「すべての端末からログアウト」のような機能があるので、ほかの場所で使われているセッションをまとめて終わらせましょう。
ログアウトがすんだらすぐにパスワードを変え、登録しているメールアドレスや電話番号、多要素認証の設定が書き換えられていないかを確かめます。
攻撃者が自分の連絡先や認証アプリを登録していると、あとから何度でも入り直されるおそれがあるからです。
最後に、ふだん使っている端末をウイルス対策ソフトで検査し、Cookieを盗むマルウェアが残っていないかを確かめます。
会社や学校のアカウントの場合は、自分だけで対応せず、まず管理者に連絡してください。
管理者は、利用者のセッションをまとめて取り消すなど、利用者にはできない対応をとれる場合があります。
お金の被害が出ている場合は、クレジットカード会社や金融機関、警察の相談窓口にも早めに相談しましょう。
- 身に覚えのない通知が届いたら、メール内のリンクではなく、公式アプリやブックマークからサービスを開いて確かめる
- まずすべての端末からログアウトし、続けてすぐにパスワードを変える
すべての端末からログアウトしてパスワードを変えても不審な操作が続く場合や、端末がマルウェアに感染している疑いが残る場合は、端末そのものを調べる必要があります。
Cookieを盗むマルウェアが残っていると、何度パスワードを変えても、また乗っ取られるおそれがあるからです。
自分で調べるのが難しいときは、パソコンやスマートフォンのハッキング調査を扱う「デジタルデータフォレンジック」のような専門業者に相談する方法があり、広告主の案内では相談や見積もりは無料とされています。
サイト運営者・開発者ができる対策
4-1. CookieにSecure・HttpOnly・SameSiteを付ける
ここからは、Webサイトを作ったり運営したりする人に向けた対策です。
利用者がどれだけ気をつけても、サイトの作りに弱点があると、セッションIDは守れません。
まず基本になるのが、セッションIDを入れたCookieに、安全のための属性を付けることです。
Secure属性を付けると、Cookieは暗号化された通信でしか送られなくなり、通信の盗み見から守りやすくなります。
HttpOnly属性を付けると、ページのJavaScriptからCookieを読めなくなり、XSSでIDを抜き取られる危険を減らせます。
SameSite属性は、ほかのサイトから始まる通信にCookieを付けるかどうかを決めるもので、クロスサイトリクエストフォージェリ（CSRF）への備えになります（参考2）。
CSRFは、ログイン中の利用者のブラウザに、別のサイトから意図しない操作を送らせる攻撃です。
IDを盗むのではなくログイン状態を悪用する攻撃なので、SameSiteはIDの盗用ではなく、ログイン状態の悪用への備えと考えてください。
OWASPも、セッションIDを入れたCookieにこれらの属性を付けることや、サイト全体をHTTPSにすること、有効期限を持たせないCookieを使うことを勧めています（参考1）。
有効期限を持たないCookieはブラウザを閉じると消えるのが基本なので、端末にIDが長く残りにくくなります。
| 属性 | 働き | 主に備える手口 |
|---|---|---|
| Secure | HTTPSの通信でだけ送る | 通信の盗み見 |
| HttpOnly | JavaScriptから読めなくする | XSSによる抜き取り |
| SameSite | ほかのサイトから始まる通信に付けにくくする | CSRF（ログイン状態の悪用） |
ただし、HttpOnlyはCookieの読み取りを防ぐもので、XSSの弱点そのものをなくすわけではありません。
属性はあくまで被害を減らす備えなので、4-3で見る弱点への対策と組み合わせることが大切です。
4-2. ログインでIDを作り直し、有効期限を決める
次に大切なのが、セッションIDを発行するタイミングと、使える期間の管理です。
2-3で見たセッションIDの固定化を防ぐには、ログインに成功した時点で、それまでのIDを捨てて新しいIDを発行します。
OWASPは、ログインのように利用者の権限が変わる場面では、必ずセッションIDを作り直すよう求めています。
図のように、セッションには終わりを決めておくことも大切です。
終わらせ方には、操作がない時間が一定以上続いたら失効させる方法と、使い続けていても最長の期限が来たら失効させる方法の2つがあります。
OWASPは、操作がない時間による失効の目安として、重要度の高いサービスでは2〜5分、リスクの低いサービスでは15〜30分程度がよく使われると紹介しています。
ログアウトのときは、ブラウザのCookieを消すだけでなく、サーバー側でもそのセッションを無効にします（参考1）。
こうしておけば、IDが盗まれても使える時間が短くなり、被害を小さくできます。
一方で、期限が短すぎると利用者が何度もログインし直すことになるので、サービスの重要度に合わせて決めましょう。
パスワードの変更や支払いのような重要な操作の前に、もう一度パスワードを求める方法もあります。
4-3. 推測できないIDを使い、XSSなどの弱点をなくす
最後は、セッションIDそのものの強さと、IDを盗まれるきっかけになる弱点への対策です。
IPAの「安全なウェブサイトの作り方」は、セッションIDを推測が難しいものにすることに加えて、URLにセッションIDを含めないことなども対策に挙げています（参考5）。
URLにIDを含めると、閲覧の履歴や、ほかのサイトへ移るときに送られるアドレスの記録などから、IDが漏れるおそれがあるためです。
セッションIDの作り方を自分で考えるより、使っているWebアプリケーションの枠組み（フレームワーク）が用意しているセッション管理の機能を使うほうが安全です。
OWASPも、セッションIDは十分にランダムな値にし、フレームワークに組み込まれたセッション管理の仕組みを使うよう勧めています（参考1）。
また、XSSのような弱点があると、Cookieの属性を整えていても、スクリプトで利用者になりすました操作をされるおそれが残ります。
ページに表示する文字を適切に処理し、定期的に脆弱性診断を受けるなど、弱点そのものをなくす取り組みを続けましょう。
利用者のログインの記録を見て、ふだんと違う場所や端末からのアクセスに気づける仕組みを用意しておくと、乗っ取りの早期発見にもつながります。
ログインの仕組みを外部のサービスに任せている場合も、セッションの有効期限やログアウトの扱いを、そのサービスの設定で確かめておきましょう。
- セッションIDの発行と管理は、フレームワークの機能を使い、独自に作らない
- Cookieの属性、ログイン時のIDの作り直し、有効期限の3点を設定で確かめる
- XSSなどの弱点は、診断と修正を続けてなくしていく
よくある質問
5-1. セッションハイジャックでよくある質問
Q1. セッションハイジャックと不正ログインは何が違いますか？
広い意味では、セッションハイジャックも不正ログインの一種と呼ばれることがあります。
この記事では、盗んだパスワードなどを使ってログイン画面から入る攻撃を不正ログインと呼び、セッションハイジャックと比べます。
セッションハイジャックは、ログインがすんだあとのしるしを盗んで、ログイン画面を通らずに入る攻撃です。
2つの違いは、1-3の図で比べています。
Q2. HTTPSのサイトなら、セッションハイジャックは起きませんか？
通信の盗み見にはとても強くなりますが、それだけで防げるわけではありません。
XSSやマルウェア、偽サイトによる中継のように、通信の暗号化とは別の場所でIDを盗む手口があるからです。
HTTPSは、ほかの対策と組み合わせてはじめて力を発揮する土台と考えましょう。
Q3. 多要素認証を使っても意味がないのですか？
いいえ、パスワードが盗まれたときの被害を防ぐ、とても大切な対策です。
MITRE ATT&CKは、ログイン先のドメインを確かめながら動く物理的なセキュリティキーなら、中継による盗み取りを防げると説明しています（参考3）。
多要素認証を使ったうえで、ログインの入口を確かめる習慣を組み合わせましょう。
Q4. ブラウザを閉じれば、ログアウトしたことになりますか？
サイトや設定によって異なります。
MDNによると、有効期限を決めていないCookieはブラウザを閉じると消えるのが基本ですが、前回の状態を復元する機能によって残る場合もあります（参考2）。
「ログインしたままにする」を選んでいると、ブラウザを閉じてもログイン状態が残ることがあるので、共用の端末では必ずログアウトのボタンを押しましょう。
Q5. Cookieを削除すれば、盗まれたセッションも使えなくなりますか？
手元のCookieは消えますが、すでに盗まれたIDまで使えなくなるとは限りません。
IDが使えなくなるのは、サイトのサーバー側でそのセッションが終わったときだからです。
OWASPも、Cookieを消すだけでは、盗まれたIDの写しは無効にならないと説明しています（参考1）。
盗まれた心配があるときは、3-3の順番で、すべての端末からログアウトしましょう。
ここまで読んでくださって、ありがとうございます。
セッションハイジャックは、パスワードではなく「ログイン済みのしるし」を狙う攻撃です。
利用者にできることは、安全な通り道でログインし、使い終わったらログアウトし、怪しいリンクやソフトを避けることです。
サイトを作る側は、Cookieの属性、IDの作り直しと有効期限、そして弱点をなくす取り組みで、そのしるしを守ります。
どれか1つで完全に防げる対策はないので、通り道・端末・サイトの3か所で、少しずつ守りを重ねることが大切です。
今日できることを1つ選ぶなら、よく使うサービスのセキュリティ設定を開き、ログイン中の端末の一覧に見覚えのないものがないかを確かめてみてください。
Cookieの仕組みや、関連する攻撃をもっと知りたい方は、次の記事もどうぞ。
