Webサイトにログインした後、何度もパスワードを入力せずに操作を続けられるのは、第1回で学んだ「Cookie（クッキー）」を利用したセッション管理のおかげです。しかし、この便利な仕組みの隙を突き、ユーザーの「ログイン状態」そのものを盗み取る攻撃が存在します。それがセッションハイジャックです。
今回は、これまでの連載で触れてきた「XSS」や「HTTPS」といった知識を総動員し、セッションハイジャックの正体と、その強固な防ぎ方を深掘りします。
セッションハイジャックの正体：合鍵のコピー
セッションハイジャックとは、攻撃者が他人の「セッションID」を何らかの方法で入手し、そのユーザーになりすましてWebサイトにアクセスする攻撃のことです。
Webサーバーは、送られてきたセッションIDが正しければ、それが「本人」からのものだと判断してしまいます。つまり、セッションIDはログイン後の世界における「合鍵」のようなものです。この鍵をコピーされてしまうと、パスワードを知らなくても、二要素認証を突破した後であっても、攻撃者は自由自在にアカウントを操作できてしまいます。
セッションIDが盗まれる「3つの主な手口」
攻撃者がどうやって「合鍵」を手に入れるのか、その代表的な手法は以下の通りです。
① ネットワーク上での盗聴（スニフィング）
暗号化されていない「HTTP」通信を利用している場合、通信経路上の第三者がパケットを覗き見することで、セッションIDを簡単に取得できます。
② クロスサイトスクリプティング（XSS）による奪取
第20回で解説した「XSS（クロスサイトスクリプティング）」を悪用する手口です。罠のリンクを踏ませ、ブラウザ上でJavaScriptを実行させることで、document.cookie からセッションIDを読み取り、攻撃者のサーバーへ送信させます。
③ セッションIDの推測と固定化（Session Fixation）
セッションIDが連番など予測しやすいルールで作られている場合、攻撃者はIDを推測して「当てずっぽう」でなりすましを試みます。また、攻撃者が用意したセッションIDをあらかじめユーザーに使わせる「セッション固定化攻撃」という巧妙な手法も存在します。
被害の深刻さ：なりすましの恐怖
セッションハイジャックが成功すると、以下のような致命的な被害が発生します。
- 個人情報の漏洩： 住所、氏名、購入履歴、クレジットカード情報などの閲覧。
- 不正操作： 勝手な商品の購入、パスワードの変更、SNSでの不適切な投稿。
- 踏み台： 権限を持ったユーザーになりすまして、社内システムへさらなる攻撃を仕掛ける。
エンジニアが実装すべき「5層の防御策」
セッションハイジャックを防ぐには、単一の対策ではなく、多層的な防御が必要です。
1. HttpOnly属性とSecure属性の付与
Cookieを発行する際、JavaScriptからのアクセスを禁止する HttpOnly 属性と、HTTPS通信時のみ送信を許可する Secure 属性を必ず設定します。これにより、XSSによる奪取と通信経路での漏洩を同時に防ぎます。
2. ログイン後のセッションID再発行
ログインに成功した直後、それまで使っていたセッションIDを破棄し、新しいIDを発行（Session ID Regeneration）します。これにより、ログイン前のIDを悪用する「セッション固定化攻撃」を無効化できます。
3. セッションタイムアウトの適切な設定
無操作状態が続いた場合にセッションを無効化したり、一定時間ごとに強制ログアウトさせたりすることで、万が一IDが漏洩しても、悪用できる時間を最小限に抑えます。
4. WAFによる攻撃遮断
「WAF」を導入し、セッションIDを狙う不審なスクリプトや、セッション固定化を狙ったリクエストを入り口で遮断します。
5. HSTSの導入
ブラウザに対し、常にHTTPSで接続することを強制する「HSTS（HTTP Strict Transport Security）」を設定します。これにより、暗号化されていない接続への「ダウングレード攻撃」を防ぎます。
まとめ：セッション管理こそセキュリティの要
セッションハイジャックは、Webアプリケーションの利便性の裏にある最大の弱点です。
- セッションIDは、ログイン状態を維持する「合鍵」。
- HTTPS、XSS対策（サニタイジング）、Cookie属性設定が防御の3本柱。
- WAFやID再発行を組み合わせた多層防御が、実務上のスタンダード。
これまで学んできた各技術（Cookie、HTTPS、WAF、脆弱性対策）は、すべてこの「セッションの安全」を守るために繋がっています。これらを体系的に理解することで、初めて「本当に安全なWebサイト」を構築することが可能になります。
コメント