セッションハイジャック

コンピュータサイエンスにおいて、セッションハイジャック（クッキーハイジャックとも呼ばれる）とは、有効なコンピュータセッション（セッションキーとも呼ばれる）を悪用して、コンピュータシステムの情報やサービスに不正にアクセスすることです。特に、リモートサーバーに対してユーザーを認証するために使用されるマジッククッキーの盗難を指します。多くのウェブサイトでセッションを維持するために使用されるHTTPクッキーは、中間コンピュータを使用するか、被害者のコンピュータに保存されたクッキーにアクセスすることで、攻撃者によって簡単に盗まれる可能性があるため、ウェブ開発者にとって特に重要です（HTTPクッキー盗難を参照）。適切なセッションクッキーを盗むことに成功した後、攻撃者はPass the Cookieテクニックを使用してセッションハイジャックを実行する可能性があります。クッキーハイジャックは、インターネット上のクライアント認証に対してよく使用されます。最新のウェブブラウザは、ウェブを攻撃から保護するためにクッキー保護メカニズムを使用しています。^[1]

一般的な方法は、ソースルート IP パケットを使用することです。これにより、ネットワーク上のポイントBにいる攻撃者は、IP パケットがB のマシンを通過するように誘導することで、 AとCの間の会話に参加できるようになります。

ソースルーティングがオフになっている場合、攻撃者は「ブラインド」ハイジャックを使用して、2 台のマシンの応答を推測できます。したがって、攻撃者はコマンドを送信できますが、応答を見ることはできません。ただし、一般的なコマンドは、ネット上の他の場所からアクセスできるようにするパスワードを設定することです。

攻撃者は、スニッフィング プログラムを使用してAとCの間に「インライン」で入り、会話を監視することもできます。これは「中間者攻撃」として知られています。

HTTP プロトコル バージョン 0.8 および 0.9 には、セッション ハイジャックに必要な Cookie やその他の機能がありませんでした。1994 年 10 月 13 日にリリースされた Mosaic Netscape のバージョン 0.9beta では、Cookie がサポートされました。

HTTP 1.0 の初期バージョンにはセッション ハイジャックに関するセキュリティ上の弱点がいくつかありましたが、初期の HTTP 1.0 サーバーとブラウザーのほとんどが不安定だったため、それを悪用するのは困難でした。HTTP 1.0 は 2000 年代初頭から HTTP 1.1 のフォールバックとして指定されており、HTTP 1.0 サーバーはすべて本質的に HTTP 1.1 サーバーであるため、セッション ハイジャックの問題はほぼ永続的なセキュリティ リスクに発展しました。^{[2] [検証失敗]}

スーパークッキーやその他の機能が近代化された HTTP 1.1 に導入されたことにより、ハイジャックの問題が継続的なセキュリティ問題となりました。Web サーバーとブラウザーのステート マシンの標準化も、この継続的なセキュリティ問題の一因となっています。

セッション ハイジャックを実行するために使用される主な方法は 4 つあります。

• セッション固定。攻撃者は、たとえば、特定のセッション ID を含むリンクを記載した電子メールをユーザーに送信して、ユーザーのセッション ID を既知の ID に設定します。攻撃者は、ユーザーがログインするまで待つだけで済みます。
• セッションサイドジャッキングでは、攻撃者はパケットスニッフィングを使用して2者間のネットワークトラフィックを読み取り、セッションCookieを盗みます。多くのWebサイトでは、攻撃者がパスワードを見るのを防ぐためにログインページにSSL暗号化を使用していますが、認証されたサイトの残りの部分には暗号化を使用していません。これにより、ネットワークトラフィックを読み取ることができる攻撃者は、サーバーに送信されるすべてのデータやクライアントが表示するWebページを傍受できます。このデータにはセッションCookieが含まれるため、パスワード自体が侵害されていなくても、攻撃者は被害者になりすますことができます。^[3] セキュリティで保護されていないWi-Fiホットスポットは特に脆弱で、ネットワークを共有している人は誰でも通常、他のノードとアクセスポイント間のWebトラフィックのほとんどを読み取ることができます。
• クロスサイト スクリプティングでは、攻撃者がユーザーのコンピューターを騙して、サーバーに属しているように見えるため信頼できるものとして扱われるコードを実行させ、Cookie のコピーを取得したり、その他の操作を実行したりします。
• マルウェアや迷惑プログラムは、ブラウザハイジャックを利用して、ユーザーに知られずにブラウザのCookieファイルを盗み、ユーザーに知られずにアクション（Androidアプリのインストールなど）を実行する可能性があります。 ^[4]物理的にアクセスできる攻撃者は、たとえば、ユーザーのコンピューターまたはサーバーの適切な部分のファイルまたはメモリの内容を取得することによって、セッションキーを盗もうとすることができます。

適切なセッションクッキーの取得に成功した攻撃者は、そのセッションクッキーをブラウザに挿入し、セッションクッキーが盗まれたウェブサイト上で被害者のユーザーになりすまします。^[5]

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

DroidSheep は、Web セッション ハイジャック (サイドジャック) 用のシンプルな Android ツールです。ワイヤレス (802.11) ネットワーク接続経由​​で送信された HTTP パケットをリッスンし、これらのパケットからセッション ID を抽出して再利用します。DroidSheep は libpcap ライブラリを使用してセッションをキャプチャでき、オープン (暗号化されていない) ネットワーク、WEP 暗号化ネットワーク、WPA/WPA2 暗号化ネットワーク (PSK のみ) をサポートしています。このソフトウェアは libpcap と arpspoof を使用します。^{[9] [10]この apk は}Google Playで入手可能でしたが、Google によって削除されました。

CookieCadger は、サイドジャックと HTTP リクエストのリプレイを自動化するグラフィカル Java アプリで、暗号化されていない GET リクエストを使用するアプリケーションからの情報漏洩を特定するのに役立ちます。これは、有線イーサネットや安全でない Wi-Fi を監視したり、パケット キャプチャ ファイルをロードしてオフライン分析を行ったりできるWiresharkスイートに基づくクロスプラットフォームのオープン ソース ユーティリティです。Cookie Cadger は、Shutterfly (AYSO サッカー リーグで使用) や TeamSnap などのユース チーム共有サイトの弱点を指摘するために使用されています。^[11]

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

これはセキュリティ研究者のマイク・ペリーが開発したPythonベースのツールです。ペリーは2007年にBugTraqでCookieMonsterが悪用した脆弱性を最初に発表しました。1年後、彼はDefcon 16で概念実証ツールとしてCookieMonsterを実演しました。^{[13] [14] [15] [16] [ 17] [18] [19] [20]}

セッションハイジャックを防ぐ方法は次のとおりです。

• SSL / TLS を使用して、当事者間でやり取りされるデータ トラフィックを暗号化します。特にセッション キー (理想的にはセッション全体のすべてのトラフィック^[21] )。この手法は、スニッフィング スタイルの攻撃を完全に防ぐため、Web ベースの銀行やその他の電子商取引サービスで広く使用されています。ただし、他の種類のセッション ハイジャックを実行することは依然として可能です。これに対して、ナイメーヘン ラドバウド大学の科学者は、アプリケーション セッションをSSL / TLS資格情報と関連付けることでセッション ハイジャックを防ぐ方法を 2013 年に提案しました^[22]
• 長い乱数または文字列をセッション キーとして使用します。これにより、攻撃者が試行錯誤やブルート フォース攻撃によって有効なセッション キーを簡単に推測できるリスクが軽減されます。
• ログインが成功した後にセッション ID を再生成します。これにより、攻撃者はログイン後のユーザーのセッション ID を知らないため、セッション固定を防止できます。
• 一部のサービスでは、ユーザーの身元に対して二次的なチェックを行っています。たとえば、Web サーバーは、リクエストごとにユーザーの IP アドレスがそのセッション中に最後に使用されたものと一致するかどうかをチェックします。ただし、これでは同じ IP アドレスを共有する誰かによる攻撃を防ぐことはできず、ブラウジング セッション中に IP アドレスが変わる可能性のあるユーザーにとってはイライラすることになります。
• あるいは、一部のサービスでは、リクエストごとに Cookie の値が変更されます。これにより、攻撃者が操作できる時間が大幅に短縮され、攻撃が行われたかどうかの特定が容易になりますが、他の技術的な問題が発生する可能性があります (たとえば、同じクライアントからの 2 つの正当なリクエストが近いタイミングで行われると、サーバー上でトークン チェック エラーが発生する可能性があります)。
• ユーザーはウェブサイトを使い終わったらいつでもログアウトしたいと考えるかもしれません。^{[23] [24]しかし、これでは}Firesheepのような攻撃から保護することはできません。

• アルプオン
• クロスサイトリクエストフォージェリ
• HTTP クッキー
• TCPシーケンス予測攻撃