LASSIC Media らしくメディア
セッションハイジャックとは｜なりすましの手口と対策
Webサービスにログインすると、その後しばらくはパスワードを入れ直さなくても操作を続けられます。これは、サーバが「ログイン済みの誰か」を識別するための合い言葉のような値を発行し、ブラウザとの間でやり取りしているからです。この合い言葉が第三者の手に渡ると、パスワードを知らなくても、その人になりすませてしまいます。これがセッションハイジャックです。
セッションハイジャックは、正規の利用者に発行されたセッションIDを攻撃者が奪い、本人になりすましてサービスを操作する攻撃です。ログインの仕組みを支える裏側を突くため、パスワードの強さだけでは防ぎきれない点に特徴があります。この記事では、発注者やプロジェクトマネージャー、これからWeb開発に関わる方に向けて、セッションハイジャックの仕組みと被害、そして開発・発注の現場でおさえておきたい対策を整理していきます。
セッションハイジャックとは何か
セッションハイジャックとは、正規の利用者に割り当てられたセッションを、攻撃者が乗っ取る攻撃を指します。「セッション」とは、ログインしてからログアウトするまでの一連のやり取りのまとまりのことで、それを識別する値が「セッションID」です。攻撃者はこのIDを手に入れ、あたかも自分がその利用者であるかのように振る舞います。
ポイントは、パスワードを盗む必要がないところにあります。セッションIDさえ握ってしまえば、サーバは「ログイン済みの本人」として扱ってくれるからです。玄関の鍵そのものではなく、入館後に配られる入館証を奪って中を歩き回るようなイメージだと捉えると、分かりやすいかもしれません。
この攻撃が狙うのは、ログインの入り口ではなく、ログインしたあとの「状態を保つ仕組み」です。だからこそ、パスワードをいくら複雑にしても、それだけでは防ぎきれません。守るべき対象が、認証情報そのものからセッションIDへと移っている点を、まず押さえておきたいところでしょう。
この記事のポイント
- セッションハイジャックは、ログイン状態を表すセッションIDを奪い、本人になりすます攻撃です。
- パスワードを知らなくても成立するため、認証の強さだけでは防ぎきれません。
- 通信の暗号化、Cookieの属性設定、セッションIDの再生成が対策の柱になります。
なぜ成立するのか（セッションIDの仕組み）
そもそもWebの通信は、一回ごとにやり取りが完結する「その場限り」の性質を持っています。サーバは、続けてアクセスしてきた相手が先ほどと同じ人かどうかを、そのままでは区別できないのです。そこで、ログインに成功した利用者へ固有のセッションIDを発行し、以降はそのIDを見て「誰か」を判断する仕組みが使われています。
このセッションIDは、多くの場合Cookieという仕組みに入れてブラウザへ渡され、次のアクセスから自動でサーバへ送られます。利用者がいちいち意識しなくても、IDが行き来することでログイン状態が保たれるわけです。下の図で、正規のやり取りと乗っ取りの流れを見てみましょう。
裏を返せば、このセッションIDが第三者に渡ってしまえば、そのIDを提示するだけでサーバは本人と信じ込みます。パスワードのように利用者の頭の中にある情報とは違い、セッションIDは通信の中を実際に流れていく値です。流れていくものである以上、どこかで盗み見られたり、抜き取られたりする隙が生まれます。そこにセッションハイジャックの成立する理由があるのです。
セッションIDが奪われる主な経路
攻撃者がセッションIDを手に入れる道筋は、ひとつではありません。代表的な経路を整理しておきます。
| 経路 | 内容 |
|---|---|
| 通信の盗み見 | 暗号化されていない通信を傍受し、流れるセッションIDを読み取る |
| スクリプトによる窃取 | クロスサイトスクリプティング（XSS）で、CookieのIDを外部へ送り出す |
| IDの推測 | 採番が単純だと、規則性から他人のセッションIDを言い当てられる |
| セッション固定 | 攻撃者が用意したIDを利用者に使わせ、ログイン後に乗っ取る |
ここで押さえておきたいのは、これらが単独でも組み合わせでも使われる点です。たとえばXSSでIDを盗む手口は、クロスサイトスクリプティング対策と地続きですし、通信の盗み見は暗号化の有無に直結します。セッションハイジャックへの備えは、周辺の脆弱性対策と切り離せない関係にあるといえるでしょう。とりわけ「セッション固定」は、あらかじめ攻撃者が知っているIDでログインさせる点が独特で、後述する対策で重点的に手当てします。
どう防ぐのか（対策）
セッションハイジャックの対策は、「IDを盗ませない」「盗まれても使わせない」の二方向で重ねると整理しやすくなります。多くはフレームワークの標準機能やサーバ設定で実現できるものです。
| 対策 | 内容 | ねらい |
|---|---|---|
| 通信の暗号化（TLS） | サイト全体をHTTPSにし、通信路でIDを読み取られないようにする | 盗み見を防ぐ |
| Cookieの属性設定 | HttpOnly・Secure・SameSiteを付け、スクリプトや別サイトからの持ち出しを抑える | 窃取を防ぐ |
| セッションIDの再生成 | ログイン時や権限が変わる時にIDを発行し直す | セッション固定を封じる |
| 推測されないID | 十分に長く、規則性のないランダムな値を用いる | 言い当てを防ぐ |
| 適切な失効 | 一定時間で切れるようにし、ログアウトでもれなく破棄する | 悪用の窓を狭める |
これらは、どれか一つで足りるものではなく、重ねてこそ効いてきます。通信を暗号化して盗み見を封じ、Cookieの属性でスクリプト経由の持ち出しを抑え、ログインのたびにIDを作り直してセッション固定を退ける——という具合に、経路ごとに手を打っていくわけです。加えて、送金や設定変更のような重い操作の前に、あらためて本人確認のひと手間を挟んでおくと、万一IDが渡っても被害を抑えやすくなります。
発注・開発でおさえる点
セッションハイジャックへの備えは、個々の画面の作り込みというより、システム全体のセッション管理の方針に関わります。発注や設計の段階で意識しておきたい点を挙げておきます。
フレームワークの機能を活かす
主要な開発フレームワークには、セッション管理の仕組みがあらかじめ備わっています。IDの生成や再生成、Cookieの属性付けといった処理を独自に作り込むより、実績のある標準機能に任せるほうが、抜けや不備を招きにくいものです。「セッション管理は自前で作らず、フレームワークの機能を用いる」ことを方針として決めておくとよいでしょう。
Cookieの属性と暗号化を要件に含める
「サイト全体をHTTPSにする」「セッションのCookieにHttpOnly・Secure・SameSiteを付ける」といった具体的な作法を、要件定義や設計書に書き入れておきます。これらは後から足すと漏れやすいため、最初から前提として明記しておくと、実装時の判断がぶれにくくなります。
ログイン前後の挙動を確認する
公開前のテストでは、ログインの前後でセッションIDが変わるか、ログアウト後に以前のIDが使えなくなるかを確かめます。あわせて、CookieにHttpOnlyなどの属性が付いているかも点検します。ブラウザの開発者ツールで実際のCookieやヘッダを見れば、設定の抜けに気づきやすくなるはずです。
よくある誤解と勘所
セッションハイジャックは、認証まわりの話と混同されやすく、対策の的を外しがちです。代表的なつまずきを表にまとめました。
| よくある誤解 | 実際のところ |
|---|---|
| パスワードを強くすれば防げる | 狙いはログイン後のセッションID。認証の強さとは別の備えが要る |
| ログインページだけHTTPSなら十分 | ログイン後もIDは流れ続ける。サイト全体の暗号化が前提になる |
| セッションIDは短いほうが扱いやすい | 短く規則的だと推測されやすい。長くランダムであることが守りになる |
| ログアウトは利用者任せでよい | 失効やタイムアウトを備え、放置されたIDの悪用の窓を狭める |
勘所をひとことでいえば、「ログインした後こそ守る」という視点を持つことです。認証は入り口の守りですが、セッションハイジャックが狙うのは入館後の入館証にあたるセッションIDです。だからこそ、通信の暗号化やCookieの属性、IDの再生成といった、状態を保つ仕組みそのものへの手当てが要になります。この見取り図を持っておくと、どこに投資すべきかが判断しやすくなるでしょう。
まとめ
- セッションハイジャックは、ログイン状態を表すセッションIDを奪い、本人になりすます攻撃である。
- Webはその場限りの通信のため、セッションIDで利用者を識別しており、そのIDが狙われる。
- 奪われる経路は、通信の盗み見・XSSによる窃取・IDの推測・セッション固定などがある。
- 対策は、通信の暗号化、CookieのHttpOnly等の属性、ログイン時のID再生成、推測されないIDが柱。
- パスワードの強化だけでは防げず、ログイン後の状態管理そのものを守る視点が欠かせない。
よくある質問
セッションハイジャックとセッション固定はどう違うのですか。
セッション固定は、セッションハイジャックを成立させる手口の一つと捉えると整理しやすくなります。通常の乗っ取りは、正規利用者に発行されたIDを後から奪う流れですが、セッション固定では、攻撃者があらかじめ用意したIDを利用者に使わせ、その人がログインした後に同じIDで入り込みます。いずれも他人のセッションを乗っ取る点は同じで、ログイン時にIDを発行し直す対策が、とりわけセッション固定に有効です。
パスワードを複雑にすれば防げますか。
パスワードの強化は大切ですが、それだけでは防ぎきれません。セッションハイジャックが狙うのは、ログインを終えた後に発行されるセッションIDであり、パスワードそのものではないためです。IDが通信の途中で盗み見られたり、スクリプトで抜き取られたりすれば、パスワードを知らなくてもなりすましは成立します。認証の強化とあわせて、通信の暗号化やCookieの属性設定など、ログイン後の守りを重ねることが欠かせません。
CookieのHttpOnlyやSecureは、どんな意味を持ちますか。
いずれもCookieの扱いを制限し、セッションIDを守るための属性です。HttpOnlyを付けると、ページ内のスクリプトからCookieを読めなくなり、XSSによる窃取を抑えられます。Secureを付けると、暗号化された通信のときだけCookieが送られ、平文での漏れを防げるのです。さらにSameSiteを付けると、別サイトを起点としたリクエストでの送信を制限できます。これらを組み合わせて設定することが、セッションIDの持ち出しへの備えになります。
セッションIDは、どのようなときに作り直すべきですか。
代表的なのは、ログインに成功した瞬間と、権限が変わる操作を行った瞬間です。ログイン時にIDを発行し直すと、あらかじめ攻撃者が用意したIDでログインさせるセッション固定を退けられます。また、一般利用者から管理者へと権限が上がる場面などでも作り直しておくと、以前のIDを使い回されるリスクを下げられます。加えて、一定時間の無操作で失効させ、ログアウト時にはIDを破棄する運用も組み合わせるとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、Webアプリケーションのセキュリティ要件の整理から設計・実装、公開済みシステムの点検・改修までを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。セッション管理をはじめとするセキュリティ対策でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
出典
- IPA「安全なウェブサイトの作り方」（セッション管理の不備）
- OWASP Cheat Sheet Series「Session Management」
- MDN Web Docs「Set-Cookie」
