セッションハイジャック
セッションハイジャック
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/07/23 08:43 UTC 版)
セッションハイジャックとは、コンピュータネットワーク通信におけるセッション（特定利用者間で行われる一連の通信群）を、通信当事者以外が乗っ取る攻撃手法である。HTTPにおけるWebセッションのハイジャックを指すことが多いが、この用語が示す範囲は必ずしもこれに限定されるわけではない。クッキーに操作を加えることから、クッキーハイジャックとも呼ばれる。
概要
ネットワーク通信では当事者間で複数回の通信をやりとりしながら一連の処理を行う事があり、このような一連の処理をセッションと呼ぶ。たとえばユーザがWebアプリケーションを使うとき、ユーザがそのアプリケーションにログインし、アプリケーションと「双方向」通信を行い、最後にログアウトするまでを１つのセッションとみなす事ができる。またストリーミングによる動画配信では、動画配信が始まってから完了するまで「連続」してデータを送り、これも１つのセッションとみなせる。このような「双方向」や「連続」を伴う一連のやり取りが一つの「セッション」として管理される。
各セッションは、セッションごとに割り振られるセッションIDを用いて識別され、通信の当事者同士は通信の際にセッションIDを送りあうことでどのセッションに関する通信であるのかを明示する。
セッションハイジャックは通信の当事者でない第三者（攻撃者）が何らかの手段でセッションIDを知ることにより、セッションを乗っ取る攻撃手法を指す。これを悪用すると、例えばユーザが銀行のシステムにログインして利用しているセッションを乗っ取り、ユーザの口座から攻撃者の口座に不正に振り込みを行う、といった事ができてしまう可能性がある。
というのも、銀行システムを含めたWeb上のアプリケーションではユーザが最初にログインする際にはパスワードの入力を求めるなどしてユーザを認証するが、一度ユーザがログインに成功したら、以後の通信ではパスワードを求めずにセッションIDのみでユーザを識別する実装になっていることも多いからである。したがってユーザがログインした後に攻撃者がセッションIDの奪取に成功すれば、攻撃者がユーザのパスワードを知らなくともセッションを乗っ取って不正をはたらく事が可能である。二重認証をバイパスしてログインすることもできる[1]。
HTTPセッション
HTTPはもともとブラウザの要求に対してWebページを返すような一往復の通信が想定されており、HTTPそれ自身はセッション管理の仕組みを備えていないため、Webアプリケーションの側でセッション管理の仕組みを用意し、ブラウザ側にセッションIDを持たせる必要がある。しかしこのセッション管理の仕組みが不適切であると、セッションをハイジャックされてしまう危険がある。
手法
Webアプリケーションに対するセッションハイジャックは以下の三種類に分類できる[2][3]：セッションIDの推測、セッションIDの盗み出し、セッションID固定化攻撃。第一の方法であるセッションIDの推測は、セッションIDを推測しやすい方法で割り振っている場合に可能な攻撃で、例えばセッションIDを連番、時刻[4]、ユーザID[4]、メールアドレス[4]といったものにしていると、攻撃者にセッションIDを推測される危険がある。
第二の方法であるセッションIDの盗難は、Webアプリケーションの脆弱性（例えばクロスサイトスクリプティング[2]、HTTPヘッダ・インジェクション[2]、ミドルウェアの脆弱性[2]）がある場合に可能な攻撃で、これらの脆弱性を利用してブラウザに保管されたセッションIDを盗む。またセッションIDをURLに埋め込んでいるケースではリファラを悪用した以下のような盗難方法が知られている[5]
- 例えばSNSのユーザのセッションをハイジャックする場合、攻撃者は標的となるユーザに自身のサイトへのリンクをSNS経由で伝える。ユーザがSNS上のリンクをクリックして攻撃者のサイトにアクセスすると、攻撃者のサイトにはユーザが直前にいたサイト（すなわちSNS）のURLがリファラとして伝わるので、SNSのサイトでセッションIDをURLに埋め込んでいる場合には、攻撃者にセッションIDが知られてしまう。
適切なセッションクッキーの取得に成功した後、攻撃者はそのセッションクッキーを自身のブラウザに注入し、クッキーが盗まれたウェブサイト上で被害者のユーザーになりすますことができる。[6]
セッションID固定化攻撃
セッションハイジャックを行う第三の方法としてセッションID固定化攻撃（セッションフィクセーション攻撃、session fixation attack）が知られている。脆弱性をツリー型に分類するCWEではセッションID固定化攻撃を不適切な認証(CWE-287)による脆弱性のひとつとして分類している(CWE-384)[7]。
前述のようにWebアプリケーションはユーザのブラウザにセッションIDを保持させる事でセッション管理を行っているが、この攻撃では何らかの不正な手段を用いて被害者のブラウザに攻撃者が用意したIDを入れ込む。これにより被害者とWebアプリケーションの間のセッションのIDは攻撃者が入れ込んだものになってしまう。攻撃者自身は当然このIDを知っているので、被害者のセッションのハイジャックが可能になる。
攻撃者がセッションIDをブラウザに入れ込む方法は様々だが、URLにセッションIDを埋め込んでいるタイプのWebアプリケーションの場合は、セッションID部分を攻撃者が指定したものに書き換えたURLを被害者にクリックさせる事でセッションID固定化が実現できる。一方、セッションIDをcookieに記憶させている場合は、cookieの書き換えが可能な脆弱性（クロスサイトスクリプティングやHTTPヘッダ・インジェクション）を利用してcookie内のセッションIDを攻撃者が指定したものに書き換える事ができる[8]。
攻撃者が入れ込むセッションIDは、攻撃者自身がランダムに新しく生成するケースと、Webアプリケーションとの他のセッション（例えばWebアプリケーションと攻撃者とのセッション）のIDを流用するケースとがある。前者の場合、攻撃が成功するにはWebアプリケーションの側が攻撃者の生成したセッションIDを受け入れる必要がある。Webアプリケーションの側で自身の発行したセッションIDを全て管理していれば、Webアプリケーションは攻撃者の生成したセッションIDを受け入れずにすむはずだが、Webアプリケーションの開発言語の中には自身で発行してないセッションIDすらも受け入れてしまうものがあり（例えば古いバージョンのPHP）、これが原因で攻撃が可能になってしまう場合がある。このように任意のセッションIDを受け入れてしまうという言語特性をセッションアダプションという[9]。
一方、別のセッションのIDを流用した攻撃の例としては、攻撃者はまずWebアプリケーションとセッションを貼り、そのセッションのIDを被害者のブラウザに入れ込むというものがある[10]。この場合Webアプリケーションの側で自身の発行したセッションIDを管理していても、この攻撃を防げない。なぜなら被害者のブラウザに入れ込まれたIDは、Webアプリケーション自身が（攻撃者に対して）発行した正規のIDだからである。
セッションサイドジャッキング（ウェブセッションハイジャック）
攻撃者がパケットキャプチャを用いて2者間のネットワークトラフィックを読み取り、セッションcookieを盗む手法。多くのウェブサイトでは、攻撃者にパスワードを見られるのを防ぐためにログインページでSSL暗号化を使用しているが、認証後のサイトの残りの部分では暗号化を使用していない。これにより、ネットワークトラフィックを読み取ることができる攻撃者は、クライアントによって閲覧されるウェブページやサーバに送信されるすべてのデータを傍受することができる。このデータにはセッションcookieが含まれているため、パスワード自体が漏洩していなくても、被害者になりすますことが可能となる[11] 。安全でないWi-Fiホットスポットは特に脆弱であり、ネットワークを共有している者であれば誰でも、他のノードとアクセスポイント間のウェブトラフィックのほとんどを読み取ることができる。
クロスサイトスクリプティング
Cookieの書き換えが可能な脆弱性（クロスサイトスクリプティングやHTTPヘッダ・インジェクション）を利用してcookie内のセッションIDを攻撃者が指定したものに書き換える事ができる[8]。
マルウェア
ブラウザをハイジャックし、ユーザーに知られることなくブラウザのクッキーを盗み、その後、ユーザーの知らないうちに行動（Androidアプリのインストールなど）を実行することがある[12] 。物理的にアクセスできる攻撃者は、例えば、ユーザーのコンピュータまたはサーバーの適切な部分のファイルやメモリの内容を取得することによって、単純にセッションキーを盗もうとすることがある。
セッション管理方法と対策
セッション管理方法
WebアプリケーションとブラウザがセッションIDを送受信する方法として以下の３つが知られている[3]：
- cookie
- フォームデータのhiddenフィールド
- URL
第一の方法は RFC 6265 に規定されており、WebアプリケーションがSet-Cookieレスポンスヘッダを用いてcookieを発行し、ブラウザ側がそのcookieを自動的にサーバに送り返す[3]。
第二の方法はセッションIDをフォームデータのhiddenフィールドとして渡す方法で、この方法を用いるにはページ遷移をフォームデータの送信の形で記述する必要がある[3]。
第三の方法はURLにセッションIDを含める方法だが、すでに述べたようにセッションハイジャックの危険にさらされるので、特別な理由がない限り利用すべきではない[3]。
したがって安全性を考慮した場合、第一もしくは第二の方法を用いてセッション管理を行うべきである。なお第二の方法のほうが第一の方法よりもセッションIDが攻撃者に漏れにくいが[3]、第二の方法の場合、自然なハイパーリンクを実現するためにスクリプトを利用する必要がある[3]ため実装が複雑になる。
対策方法
- セッションIDをURLパラメータに格納しない[13]。上記のとおり、悪意ある人にそのURLを入手されると、容易にセッションハイジャックされてしまう。
- ログイン成功後にセッションIDを再生成する[13]。セッションIDがログイン前に攻撃者に漏れていても、攻撃者はユーザーがログインした後のセッションIDを知らないため、セッション固定攻撃が防止される。
- SSL/TLSを使用して、当事者間で渡されるデータトラフィック、特に特にセッションキー（理想的にはセッション全体のすべてのトラフィック[14]）を暗号化する。暗号化することで、データトラフィックのスニッフィングを完全に防ぐため、ウェブベースの銀行やその他のeコマースサービスで広く利用されている。しかし、それでも他の種類のセッションハイジャックを実行することは可能である。これに対し、2013年にラードバウト大学の科学者たちは、アプリケーションセッションをSSL/TLSの資格情報と関連付けることでセッションハイジャックを防ぐ方法を提案した[15]。
- HTTPS通信で利用するCookieにはsecure属性を加える[13]。secure属性が設定されたCookieはHTTPS通信のみで利用され、盗聴対策になる。
- セッションキーとして長いランダムな数値または文字列を使用すること。これにより、攻撃者が試行錯誤や総当たり攻撃によって有効なセッションキーを単純に推測するリスクが低減される。
- ユーザーの身元に対して二次的なチェックを行う[13]。例えば、ログイン成功時に秘密情報を作成してCookieにセットし、行われた各リクエストごとに、この秘密情報とCookieの値が一致することを確認するようにする。
- セッションIDをCookieにセットする場合、有効期限を短くし、必要以上の期間、Cookieがブラウザに保存されないようにする[13]。ブラウザに一時保持されているCookieが流出した際のリスクをおさえることができる。
- リクエストごとにクッキーの値を変更する。これにより、攻撃者が活動できる時間枠が劇的に短縮され、攻撃が発生したかどうかを容易に特定できるが、他の技術的な問題（例えば、同じクライアントからの2つの正当で時間的に近接したリクエストがサーバー側でトークンチェックエラーを引き起こすなど）を引き起こす可能性がある。
- ユーザーはまた、ウェブサイトの使用が終了したら常にログアウトすることを強制する[16][17] 。しかし、これはFiresheepのような攻撃には対応できない。
- Webアプリケーションの開発時に、開発ツール（Webアプリケーションフレームワーク）を利用する。セッション管理機能を自作せず、既存の開発ツールに付属したものを利用する[18]。
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が含まれており、スクリプトを使用して他のウェブサイトを追加することも可能であった[19] 。そのわずか数ヶ月後、FacebookとTwitterはHTTPSの全面的な提供（後に必須化）で対応した。[20][21]
DroidSheep
DroidSheepは、セッションサイドジャッキング（ウェブセッションハイジャック）のためのシンプルなAndroidツールである。無線（802.11）ネットワーク接続を介して送信されるHTTPパケットを盗聴し、これらのパケットからセッションIDを抽出して再利用する。DroidSheepはlibpcapライブラリを使用してセッションをキャプチャでき、オープン（非暗号化）ネットワーク、WEP暗号化ネットワーク、およびWPA/WPA2暗号化ネットワーク（PSKのみ）をサポートしている。このソフトウェアはlibpcapとarpspoofを使用する[22][23]。 apkはかつてGoogle Playで公開されていたが、Googleによって削除された。
CookieCadger
CookieCadgerは、暗号化されていないGETリクエストを使用するアプリケーションからの情報漏洩を特定するのに役立つ、サイドジャッキングとHTTPリクエストのリプレイを自動化するグラフィカルなJavaアプリである。これは、有線イーサネット、安全でないWi-Fiを監視するか、オフライン分析のためにパケットキャプチャファイルを読み込むことができるWiresharkスイートをベースにした、クロスプラットフォームのオープンソースユーティリティである。Cookie Cadgerは、Shutterfly（AYSOサッカーリーグで使用）やTeamSnapなどの青少年チーム共有サイトの弱点を浮き彫りにするために使用されている。[24]
CookieMonster
CookieMonsterは、「暗号化セッションのみ」プロパティが適切に設定されていない場合に、第三者がHTTPSクッキーデータを取得できる中間者攻撃である。これにより、個人情報や財務情報などの機密情報を含むサイトへのアクセスが可能になる可能性がある。2008年には、Gmail、Google Docs、eBay、Netflix、CapitalOne、Expediaなどの主要なウェブサイトが影響を受ける可能性があった[25]。
これは、セキュリティ研究者のマイク・ペリーによって開発された、Pythonベースのツールである。ペリーは、CookieMonsterによって悪用される脆弱性を2007年にBugtraqで最初に発表した。1年後、彼はDefcon 16で概念実証ツールとしてCookieMonsterをデモンストレーションした。[26][27][28][29][30][31][32][33]
関連項目
脚注
- ^ “"Cookie Theft Demo: Bypass Two-Factor Authentication (2FA)"(YouTube)”. 2025年4月13日閲覧。
- ^ a b c d 徳丸 2011, p. 159.
- ^ a b c d e f g IPA 2014.
- ^ a b c 徳丸 2011, p. 161-162.
- ^ 徳丸 2011, p. 159,165-169.
- ^ Nikiforakis, Nick; Meert, Wannes; Younan, Yves; Johns, Martin; Joosen, Wouter (2011). “SessionShield: Lightweight Protection against Session Hijacking”. In Erlingsson, Úlfar; Wieringa, Roel; Zannone, Nicola (英語). Engineering Secure Software and Systems. Lecture Notes in Computer Science. 6542. Berlin, Heidelberg: Springer. pp. 89. doi:10.1007/978-3-642-19125-1_7. ISBN 978-3-642-19125-1
- ^ CWE-384 2015.
- ^ a b 徳丸 2011, p. 179.
- ^ 徳丸 2011, p. 176.
- ^ OWASP 2014.
- ^ “Warning of webmail wi-fi hijack” (英語). BBCニュース (2007年8月3日). 2025年7月23日閲覧。
- ^ “Malware use Browser Hijacking to steal cookie” (英語) (2020年10月19日). 2025年7月23日閲覧。
- ^ a b c d e “安全なウェブサイトの作り方 - 1.4 セッション管理の不備 | 情報セキュリティ”. IPA 独立行政法人 情報処理推進機構. 2025年7月23日閲覧。
- ^ “Schneier on Security: Firesheep” (英語) (2010年10月27日). 2025年7月23日閲覧。
- ^ Burgers, Willem; Roel Verdult; Marko van Eekelen (2013). “Prevent Session Hijacking by Binding the Session to the Cryptographic Network Credentials” (英語). Secure IT Systems. Lecture Notes in Computer Science. 8208. pp. 33–50. doi:10.1007/978-3-642-41488-6_3. ISBN 978-3-642-41487-9
- ^ 参照 “NetBadge: How To Log Out” (英語). 2025年7月23日閲覧。
- ^ 参照 “Be Card Smart Online - Always log out” (英語). 2025年7月23日閲覧。
- ^ 徳丸 2011, p. 183.
- ^ “Firefox extension steals Facebook, Twitter, etc. sessions” (英語). The H. (2010年10月25日). オリジナルの2024年3月6日時点におけるアーカイブ。 2025年7月23日閲覧。
- ^ “Facebook now SSL-encrypted throughout” (英語). The H. (2011年1月27日) 2025年7月23日閲覧。
- ^ “Twitter adds 'Always use HTTPS' option” (英語). The H. (2011年3月16日) 2025年7月23日閲覧。
- ^ “DroidSheep” (英語). 2025年7月23日閲覧。
- ^ “DroidSheep Blog” (英語). 2016年11月20日時点のオリジナルよりアーカイブ。2025年7月23日閲覧。
- ^ “How Shutterfly and Other Social Sites Leave Your Kids Vulnerable to Hackers” (英語). Mother Jones (2013年5月3日). 2024年5月19日時点のオリジナルよりアーカイブ。2025年7月23日閲覧。
- ^ Goodwin, Dan. “CookieMonster nabs user creds from secure sites • The Register” (英語). www.theregister.co.uk. 2025年7月23日閲覧。
- ^ Perry, Mike (2008年8月4日). “CookieMonster: Cookie Hijacking” (英語). fscked.org. 2025年7月23日閲覧。
- ^ Claburn, Thomas (2008年9月11日). “CookieMonster Can Steal HTTPS Cookies -- Security -- InformationWeek” (英語). InformationWeek. 2008年9月12日時点のオリジナルよりアーカイブ。2025年7月23日閲覧。
- ^ Goodin, Dan (2008年9月11日). “CookieMonster nabs user creds from secure sites” (英語). www.theregister.co.uk. 2025年7月23日閲覧。
- ^ Perry, Mike (2008年8月24日). “Incomplete List of Alleged Vulnerable Sites” (英語). fscked.org. 2025年7月23日閲覧。
- ^ Prince, Brian (2008年9月12日). “HTTPS Cookie-Hijacking Tool CookieMonster Gobbles Personal Data” (英語). eWeek. Ziff-Davis. 2024年10月29日時点のオリジナルよりアーカイブ。2025年7月23日閲覧。
- ^ “Perry's Defcon Presentation (YouTube)” (英語). YouTube. 2025年7月23日閲覧。
- ^ “Defcon Presentation slides” (英語). 2025年7月23日閲覧。
- ^ “CookieMonster Core Logic, Configuration, and READMEs” (英語). 2025年7月23日閲覧。
参考文献
- 徳丸浩『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』SBクリエイティブ、2011年3月1日。 ISBN 978-4797361193。
- “CWE-384: Session Fixation”. MITRE (2015年12月8日). 2016年9月15日閲覧。
- “Session fixation”. OWASP (2014年8月14日). 2016年9月15日閲覧。
- “セキュアプログラミング講座 Webアプリケーション編 第4章 セッション対策セッション乗っ取り：#1 セッションIDとセッションID侵害手口”. 情報処理推進機構(IPA) (2014年10月2日). 2016年9月15日閲覧。
- “米CERT/CCが警告したTCPスタックの深刻なぜい弱性”. 日経BP. 2009年1月28日閲覧。
- “「セッション管理」のすべて”. 日経BP. 2009年1月28日閲覧。
 |
この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |
セッションハイジャック
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/06/06 15:37 UTC 版)
「HTTP cookie」の記事における「セッションハイジャック」の解説
クッキーでセッション管理を行う場合、もし第三者がセッションIDを知ることができれば、そのIDを名乗ることで本来のユーザになりすますことができる。このような「なりすまし」行為をセッションハイジャックと呼ぶ。 例として、以下のような通信を行うシステムがあるとする。 トップページでユーザIDとパスワードの入力を求める。 認証に成功するとサーバはセッションIDを割り当て、クッキーとしてクライアントに通知する。 クライアントは以降の要求にクッキーとしてセッションIDを付加する。サーバは対応するセッション情報にアクセスし、どのユーザであるか識別する。 もし第三者がセッションIDを知ることができれば、そのセッションが有効な間だけとはいえ、1～2を飛ばして3から開始することができる。すなわち、パスワードを知らなくても「なりすまし」が可能となる。 第三者のクッキー情報を知る方法のひとつは盗聴である。盗聴を防ぐ手段としてTLSがある。ただしここで、クッキーは有効範囲内のすべての要求に対して自動的に付加されることに注意する必要がある。SSLでクッキー情報を暗号化しているつもりでも、有効範囲の設定によっては、SSLを利用しない要求にもクッキーが付加される可能性がある。情報処理推進機構は2003年8月に、この点に関する注意喚起を行った。 クロスサイトスクリプティングも、クッキー情報を不正に得る手段として使われる場合がある。クッキーには有効範囲が設定されているが、その有効範囲内にクロスサイトスクリプティング脆弱性を持つページがある場合、JavaScript等を併用して、他のサーバにクッキー情報を（URLの一部に組み込むなどして）送信させることが可能になる。
※この「セッションハイジャック」の解説は、「HTTP cookie」の解説の一部です。
「セッションハイジャック」を含む「HTTP cookie」の記事については、「HTTP cookie」の概要を参照ください。
- セッション・ハイジャックのページへのリンク
