セッションハイジャック

**セッションハイジャック**とは、コンピュータネットワーク通信におけるセッション（特定利用者間で行われる一連の通信群）を、通信当事者以外が乗っ取る攻撃手法である。HTTPにおけるWebセッションのハイジャックを指すことが多いが、この用語が示す範囲は必ずしもこれに限定されるわけではない。クッキーに操作を加えることから、クッキーハイジャックとも呼ばれる。

## 概要
ネットワーク通信では当事者間で複数回の通信をやりとりしながら一連の処理を行う事があり、このような一連の処理を**セッション**と呼ぶ。たとえばユーザがWebアプリケーションを使うとき、ユーザがそのアプリケーションにログインし、アプリケーションと「双方向」通信を行い、最後にログアウトするまでを１つのセッションとみなす事ができる。またストリーミングによる動画配信では、動画配信が始まってから完了するまで「連続」してデータを送り、これも１つのセッションとみなせる。このような「双方向」や「連続」を伴う一連のやり取りが一つの「セッション」として管理される。

各セッションは、セッションごとに割り振られる**セッションID**を用いて識別され、通信の当事者同士は通信の際にセッションIDを送りあうことでどのセッションに関する通信であるのかを明示する。

**セッションハイジャック**は通信の当事者でない第三者（攻撃者）が何らかの手段でセッションIDを知ることにより、セッションを乗っ取る攻撃手法を指す。これを悪用すると、例えばユーザが銀行のシステムにログインして利用しているセッションを乗っ取り、ユーザの口座から攻撃者の口座に不正に振り込みを行う、といった事ができてしまう可能性がある。

というのも、銀行システムを含めたWeb上のアプリケーションではユーザが最初にログインする際にはパスワードの入力を求めるなどしてユーザを認証するが、一度ユーザがログインに成功したら、以後の通信ではパスワードを求めずにセッションIDのみでユーザを識別する実装になっていることも多いからである。したがってユーザがログインした後に攻撃者がセッションIDの奪取に成功すれば、攻撃者が**ユーザのパスワードを知らなくとも**セッションを乗っ取って不正をはたらく事が可能である。二重認証をバイパスしてログインすることもできる。

## HTTPセッション

HTTPはもともとブラウザの要求に対してWebページを返すような一往復の通信が想定されており、HTTPそれ自身はセッション管理の仕組みを備えていないため、Webアプリケーションの側でセッション管理の仕組みを用意し、ブラウザ側にセッションIDを持たせる必要がある。しかしこのセッション管理の仕組みが不適切であると、セッションをハイジャックされてしまう危険がある。

## 手法

Webアプリケーションに対するセッションハイジャックは以下の三種類に分類できる：セッションIDの推測、セッションIDの盗み出し、セッションID固定化攻撃。第一の方法である**セッションIDの推測**は、セッションIDを推測しやすい方法で割り振っている場合に可能な攻撃で、例えばセッションIDを連番、時刻、ユーザID、メールアドレスといったものにしていると、攻撃者にセッションIDを推測される危険がある。

第二の方法である**セッションIDの盗難**は、Webアプリケーションの脆弱性（例えばクロスサイトスクリプティング、HTTPヘッダ・インジェクション、ミドルウェアの脆弱性）がある場合に可能な攻撃で、これらの脆弱性を利用してブラウザに保管されたセッションIDを盗む。またセッションIDをURLに埋め込んでいるケースではリファラを悪用した以下のような盗難方法が知られている

* 例えばSNSのユーザのセッションをハイジャックする場合、攻撃者は標的となるユーザに自身のサイトへのリンクをSNS経由で伝える。ユーザがSNS上のリンクをクリックして攻撃者のサイトにアクセスすると、攻撃者のサイトにはユーザが直前にいたサイト（すなわちSNS）のURLがリファラとして伝わるので、SNSのサイトでセッションIDをURLに埋め込んでいる場合には、攻撃者にセッションIDが知られてしまう。

適切なセッションクッキーの取得に成功した後、攻撃者はそのセッションクッキーを自身のブラウザに注入し、クッキーが盗まれたウェブサイト上で被害者のユーザーになりすますことができる。

### セッションID固定化攻撃

セッションハイジャックを行う第三の方法として**セッションID固定化攻撃**（**セッションフィクセーション攻撃**、*session fixation attack*）が知られている。脆弱性をツリー型に分類するCWEではセッションID固定化攻撃を不適切な認証(CWE-287)による脆弱性のひとつとして分類している(CWE-384)。

前述のようにWebアプリケーションはユーザのブラウザにセッションIDを保持させる事でセッション管理を行っているが、この攻撃では何らかの不正な手段を用いて被害者のブラウザに攻撃者が用意したIDを入れ込む。これにより被害者とWebアプリケーションの間のセッションのIDは攻撃者が入れ込んだものになってしまう。攻撃者自身は当然このIDを知っているので、被害者のセッションのハイジャックが可能になる。

攻撃者がセッションIDをブラウザに入れ込む方法は様々だが、URLにセッションIDを埋め込んでいるタイプのWebアプリケーションの場合は、セッションID部分を攻撃者が指定したものに書き換えたURLを被害者にクリックさせる事でセッションID固定化が実現できる。一方、セッションIDをcookieに記憶させている場合は、cookieの書き換えが可能な脆弱性（クロスサイトスクリプティングやHTTPヘッダ・インジェクション）を利用してcookie内のセッションIDを攻撃者が指定したものに書き換える事ができる。

攻撃者が入れ込むセッションIDは、攻撃者自身がランダムに新しく生成するケースと、Webアプリケーションとの他のセッション（例えばWebアプリケーションと攻撃者とのセッション）のIDを流用するケースとがある。前者の場合、攻撃が成功するにはWebアプリケーションの側が攻撃者の生成したセッションIDを受け入れる必要がある。Webアプリケーションの側で自身の発行したセッションIDを全て管理していれば、Webアプリケーションは攻撃者の生成したセッションIDを受け入れずにすむはずだが、Webアプリケーションの開発言語の中には自身で発行してないセッションIDすらも受け入れてしまうものがあり（例えば古いバージョンのPHP）、これが原因で攻撃が可能になってしまう場合がある。このように任意のセッションIDを受け入れてしまうという言語特性を**セッションアダプション**という。

一方、別のセッションのIDを流用した攻撃の例としては、攻撃者はまずWebアプリケーションとセッションを貼り、そのセッションのIDを被害者のブラウザに入れ込むというものがある。この場合Webアプリケーションの側で自身の発行したセッションIDを管理していても、この攻撃を防げない。なぜなら被害者のブラウザに入れ込まれたIDは、Webアプリケーション自身が（攻撃者に対して）発行した正規のIDだからである。

### セッションサイドジャッキング（ウェブセッションハイジャック）
攻撃者がパケットキャプチャを用いて2者間のネットワークトラフィックを読み取り、セッションcookieを盗む手法。多くのウェブサイトでは、攻撃者にパスワードを見られるのを防ぐためにログインページでSSL暗号化を使用しているが、認証後のサイトの残りの部分では暗号化を使用していない。これにより、ネットワークトラフィックを読み取ることができる攻撃者は、クライアントによって閲覧されるウェブページやサーバに送信されるすべてのデータを傍受することができる。このデータにはセッションcookieが含まれているため、パスワード自体が漏洩していなくても、被害者になりすますことが可能となる 。安全でないWi-Fiホットスポットは特に脆弱であり、ネットワークを共有している者であれば誰でも、他のノードとアクセスポイント間のウェブトラフィックのほとんどを読み取ることができる。

### セッションポイズニング

サーバーアプリケーション内の不十分な入力検証を悪用することで、攻撃者がウェブサイトのCookieを改ざんしたり、偽造したCookieを挿入したりして、ユーザーのセッションを乗っ取ることがある。これをセッションポイズニングという。

### クロスサイトスクリプティング

Cookieの書き換えが可能な脆弱性（クロスサイトスクリプティングやHTTPヘッダ・インジェクション）を利用してcookie内のセッションIDを攻撃者が指定したものに書き換える事ができる。

### マルウェア
ブラウザをハイジャックし、ユーザーに知られることなくブラウザのクッキーを盗み、その後、ユーザーの知らないうちに行動（Androidアプリのインストールなど）を実行することがある 。物理的にアクセスできる攻撃者は、例えば、ユーザーのコンピュータまたはサーバーの適切な部分のファイルやメモリの内容を取得することによって、単純にセッションキーを盗もうとすることがある。

## セッション管理方法と対策

### セッション管理方法
WebアプリケーションとブラウザがセッションIDを送受信する方法として以下の３つが知られている：
# cookie
# フォームデータのhiddenフィールド
# URL

第一の方法は  に規定されており、WebアプリケーションがSet-Cookieレスポンスヘッダを用いてcookieを発行し、ブラウザ側がそのcookieを自動的にサーバに送り返す。

第二の方法はセッションIDをフォームデータのhiddenフィールドとして渡す方法で、この方法を用いるにはページ遷移をフォームデータの送信の形で記述する必要がある。

第三の方法はURLにセッションIDを含める方法だが、すでに述べたように**セッションハイジャックの危険にさらされる**ので、特別な理由がない限り利用すべきではない。

したがって安全性を考慮した場合、第一もしくは第二の方法を用いてセッション管理を行うべきである。なお第二の方法のほうが第一の方法よりもセッションIDが攻撃者に漏れにくいが、第二の方法の場合、自然なハイパーリンクを実現するためにスクリプトを利用する必要があるため実装が複雑になる。

### 対策方法
*セッションIDをURLパラメータに格納しない。上記のとおり、悪意ある人にそのURLを入手されると、容易にセッションハイジャックされてしまう。
***ログイン成功後にセッションIDを再生成する**。セッションIDがログイン前に攻撃者に漏れていても、攻撃者はユーザーがログインした後のセッションIDを知らないため、セッションID固定化攻撃が防止される。
*ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認する****。
*SSL/TLSを使用して、当事者間で渡されるデータトラフィック、特に特にセッションキー（理想的にはセッション全体のすべてのトラフィック）を暗号化する。暗号化することで、データトラフィックのスニッフィングを完全に防ぐため、ウェブベースの銀行やその他のeコマースサービスで広く利用されている。しかし、それでも他の種類のセッションハイジャックを実行することは可能である。これに対し、2013年にラードバウト大学の科学者たちは、アプリケーションセッションをSSL/TLSの資格情報と関連付けることでセッションハイジャックを防ぐ方法を提案した。
* HTTPS通信で利用するCookieにはsecure属性を加える。secure属性が設定されたCookieはHTTPS通信のみで利用され、盗聴対策になる。
* セッションキーとして長いランダムな数値または文字列を使用すること。これにより、攻撃者が試行錯誤や総当たり攻撃によって有効なセッションキーを単純に推測するリスクが低減される。
* ユーザーの身元に対して二次的なチェックを行う。例えば、ログイン成功時に秘密情報を作成してCookieにセットし、行われた各リクエストごとに、この秘密情報とCookieの値が一致することを確認するようにする。
* セッションIDをCookieにセットする場合、有効期限を短くし、必要以上の期間、Cookieがブラウザに保存されないようにする。ブラウザに一時保持されているCookieが流出した際のリスクをおさえることができる。
* リクエストごとにクッキーの値を変更する。これにより、攻撃者が活動できる時間枠が劇的に短縮され、攻撃が発生したかどうかを容易に特定できるが、他の技術的な問題（例えば、同じクライアントからの2つの正当で時間的に近接したリクエストがサーバー側でトークンチェックエラーを引き起こすなど）を引き起こす可能性がある。
* ユーザーはまた、ウェブサイトの使用が終了したら常にログアウトすることを強制する 。しかし、これはFiresheepのような攻撃には対応できない。
* Webアプリケーションの開発時に、開発ツール（Webアプリケーションフレームワーク）を利用する。**セッション管理機能を自作せず、既存の開発ツールに付属したものを利用する**。
## TCPコネクションへの攻撃
TCPはIP通信に対してコネクション機能を設けたものであり、最低限のセッション機能を設けたものともいえる。

TCPにおいてセッションIDに相当する管理項目は、IPアドレスとシーケンス番号である。送信元IPアドレスの詐称とTCPシーケンス番号予測攻撃を組み合わせることで、確立済みのTCPセッションに不正データを挿入することやセッションの強制切断を行うことが可能であり、セッションの乗っ取りが可能となる。

TCPシーケンス番号予測攻撃について、1985年にBob Morrisが攻撃手法をレポートしたこと、1995年にこの脆弱性を使った広範囲の攻撃が発生したこと（CA-1995-01）、2001年に不充分な実装に伴う問題が指摘されたこと（CA-2001-09）など、過去より何度か問題となっていたが、対策が行なわれている2008年現在では沈静化している。
## エクスプロイト

### Firesheep

2010年10月に導入されたFirefoxの拡張機能である「Firesheep」は、安全でないネットワークにおけるセッションハイジャックの脆弱性を実証した。これは、人気のウェブサイトから暗号化されていないクッキーをキャプチャし、ユーザーが同じネットワーク上の他者のアクティブなセッションを乗っ取ることを可能にした。このツールは、潜在的なターゲットをサイドバーに表示することで機能し、パスワードを盗むことなくセッションへのアクセスを可能にした。サポートされていたウェブサイトには、Facebook、Twitter、Flickr、Amazon、Windows Live、Googleが含まれており、スクリプトを使用して他のウェブサイトを追加することも可能であった 。そのわずか数ヶ月後、FacebookとTwitterはHTTPSの全面的な提供（後に必須化）で対応した。

### DroidSheep

DroidSheepは、セッションサイドジャッキング（ウェブセッションハイジャック）のためのシンプルなAndroidツールである。無線（802.11）ネットワーク接続を介して送信されるHTTPパケットを盗聴し、これらのパケットからセッションIDを抽出して再利用する。DroidSheepはlibpcapライブラリを使用してセッションをキャプチャでき、オープン（非暗号化）ネットワーク、WEP暗号化ネットワーク、およびWPA/WPA2暗号化ネットワーク（PSKのみ）をサポートしている。このソフトウェアはlibpcapとarpspoofを使用する。 apkはかつてGoogle Playで公開されていたが、Googleによって削除された。

### CookieCadger

CookieCadgerは、暗号化されていないGETリクエストを使用するアプリケーションからの情報漏洩を特定するのに役立つ、サイドジャッキングとHTTPリクエストのリプレイを自動化するグラフィカルなJavaアプリである。これは、有線イーサネット、安全でないWi-Fiを監視するか、オフライン分析のためにパケットキャプチャファイルを読み込むことができるWiresharkスイートをベースにした、クロスプラットフォームのオープンソースユーティリティである。Cookie Cadgerは、Shutterfly（AYSOサッカーリーグで使用）やTeamSnapなどの青少年チーム共有サイトの弱点を浮き彫りにするために使用されている。

### CookieMonster

CookieMonsterは、「暗号化セッションのみ」プロパティが適切に設定されていない場合に、第三者がHTTPSクッキーデータを取得できる中間者攻撃である。これにより、個人情報や財務情報などの機密情報を含むサイトへのアクセスが可能になる可能性がある。2008年には、Gmail、Google Docs、eBay、Netflix、CapitalOne、Expediaなどの主要なウェブサイトが影響を受ける可能性があった。

これは、セキュリティ研究者のマイク・ペリーによって開発された、Pythonベースのツールである。ペリーは、CookieMonsterによって悪用される脆弱性を2007年にBugtraqで最初に発表した。1年後、彼はDefcon 16で概念実証ツールとしてCookieMonsterをデモンストレーションした。
## 関連項目
* ソース・ルーティング
* HTTP cookie
* セッションフィクセーション
* セッションポイズニング

## 脚注

## 参考文献
*
*
*
*
* 
*