セッションハイジャック

クライアント・サーバー間の正規な通信手順の途中に割り込み、サーバーとの通信をクライアントから奪取する攻撃手法。
サーバー側としては正規のクライアントと通信しているようにしか見えないため、攻撃者が不正にサービスを利用可能になってしまう。
　
利用されるのはプロトコルの仕様上・実装上の脆弱性とアプリケーションのセッション管理に関する脆弱性。
内部的な詳しい話は以下の通り
・TCPを悪用した場合
・UDPを悪用した場合
・アプリケーションレベルの手法
・想定される被害
・対策
以上目次。詳しくは続きに。
　
　

TCPを悪用した場合

TCP実装上の脆弱性をつくパターン。
TCPはコネクションを開始する際に3wayHandShakeというプロセスを踏む。
（詳細は別項：TCP/IP 3wayHandShake　を参照）
　
つまりは、通信開始要求のSYN、開始要求受諾のSYN/ACK、通信開始のACKという3段階でコネクションが確立するアレである。
　
このときクライアントとサーバーはシーケンス番号という情報をパケットに付加し、互いを判別している。逆に言えば攻撃者はこのシーケンス番号が入手できれば通信を奪取できるわけである。
　
さて、通常なら
１．クライアント　→　SYN　→　サーバー　//クライアント側のシーケンス番号通知
２．クライアント　←SYN/ACK←　サーバー　//サーバー側のシーケンス番号通知
３．クライアント　→　ACK　→　サーバー　//１でやりとりしたシーケンス番号を使用
という手順が踏まれるわけだが、
この攻撃を受けた場合
１．クライアント　→　SYN　→　サーバー　//攻撃者、SYNの送信を傍受(盗聴）
２．クライアント　←SYN/ACK←　サーバー　//攻撃者、SYN/ACKの送信を以下同
３．攻撃者　　　　→　RST　→　サーバー　//攻撃者、クライアントを装い通信をリセット
４．クライアント　→　ACK　→　サーバー　//通信はリセットされているのでエラー
５．攻撃者　　　　→　SYN　→　サーバー　//攻撃者、通信開始要求
６．クライアント　←SYN/ACK←　サーバー　//2度目のSYN/ACKなのでエラー
７．攻撃者　　　　→　ACK　→　サーバー //攻撃者、通信開始宣言
という手順が発生する。
　
もう少し詳しく見てみよう。
１．まず攻撃者はクライアントのシーケンス番号を入手する
２．つづいてサーバーのシーケンス番号も入手する。
３．ここがポイントなのだが、攻撃者はクライアントを装い通信をリセット。
　ここで１にて入手したシーケンス番号が使われる。
　（なお、RSTは本来通信エラーでパケットが届かなかった場合や何らかの理由で通信を中断する場合などに行われる、通信リセットの手続き）
　この攻撃者のリセットによりサーバーはクライアントからの接続要求を破棄する。
４．通信要求は破棄されているので、ACKはサーバー側に受理されない。
　しかしこの（ACKを送信した）時点でクライアント側は通信が確立されたと思いこむ。
　（実際は確立されていないため、その後のデータ通信でエラーが生じる）
５．攻撃者は、”クライアントからの再送を装って”SYNパケットを送る。
　このときに、攻撃者は新たなシーケンス番号をサーバーに通知
６．サーバーはこれに応じて６でSYN/ACKをクライアントに返すが、
　クライアント側はこの時点でSYN/ACKを受ける状態にないのでエラー。
　もちろん攻撃者はこのときのシーケンス番号も盗聴する。
７．攻撃者はこの６のやりとりを待ってから、ACKをサーバーに送る。
そして、サーバー側としては、SYN/ACKを送ったらACKが帰ってきた・・・つまり正規の手続きに見えるのでコネクションが確立するというわけだ。
　

UDPを悪用した手法

コネクションレス通信であるUDPにおいては、TCPほど面倒な手順はない。
セッションを乗っ取るためにはクライアントからサーバーに要求があったときに、サーバーより先に応答してやればよい。そうすればクライアントはサーバーからの応答だと思って攻撃者による不正な応答を受理する。
これを利用してDNSキャッシュを汚染するなどの二次攻撃が可能となる。
　

アプリケーションレベルの手法

セッション管理を行うアプリケーションに脆弱性があれば、それを利用することも可能。
たとえばHTTPはクッキーやセッションIDによりセッションを管理し、正規クライアントを判別するが、クライアントから送信されるこれらの情報を盗聴すれば正規クライアントになりすまして通信することが可能となる。
　

想定される被害

この攻撃手法に関しては、直接的な被害より、この攻撃で漏洩した情報を利用されることで生じる二次被害が中心と思われる。また、サーバー側、クライアント側で大きく被害の性質が異なる点も特徴的かもしれない。
具体的には、
クライアント側
・認証情報の漏洩（IDやパスワードが知られる）
・情報の改ざん（不正にログインした攻撃者がユーザー情報を書き換える）
・サービスの不正利用（有料サービスを勝手に使われる。請求が来るかも）
・不正な応答の受理（攻撃者がサーバーのフリをして不正な応答を送ってくる）
サーバー側
・不正ログイン（攻撃者が正規ユーザーのフリをしてログインしてくる）
・認証情報の改ざん（クライアント側に同じ）
　

対策

まず、盗聴を防止することが第一。
攻撃者はサーバーとクライアントのやりとりを監視・盗聴して攻撃を行うので、
通信の暗号化などをして盗聴を防止する。
また、セッションハイジャックにつながるセキュリティーホールをふさぐことも重要である。