2010年12月30日

WebSocketがデフォルトdisableとなった件



 拙著(「徹底解説 HTML5 APIガイドブック コミュニケーション系API編)の補足・修正POSTです。

 p.24にWebSocketをサポートしているブラウザが記載されていますが、周知の通り、以下のブラウザでデフォルトdisableになりました。

      FireFox4
      Opera11
 ちなみに、執筆以降サポートを開始した
      iOS4.2.1のsafari
は、現状使える状態です。

 disableとなった理由は、現状実装されているバージョン(Draft76)にセキュリティ上の脆弱性が見つかったため。脆弱性がFixされた仕様がIETFで固まれば、マイナーバージョンであっても再び対応するとのこと。
http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/

脆弱性の詳細は、Adamさんのレポートで述べられています。 ただし、今回の問題はWebSocketの脆弱性であるのはもちろんなのですが、危険度としては

      transparent proxyの脆弱性
      Java applet, Flashの脆弱性
という側面のほうが遥かに強いので、詳細を解説してみたいと思います。

 まず、transparent proxyとはなんぞや?ですが、その前に普通のproxyについて。。。proxyとはWebサービスへのアクセスに対し代理応答するサーバー。よく企業のネットワークなんかに入っています。ブラウザが、あるWebサービスにアクセスしようとした際、一旦proxyサーバーにアクセスし、proxyがWebサーバから代理でダウンロードしたファイルを、要求元のブラウザに中継する動作をします。具体的には、ブラウザは、以下のようなメッセージ(一部抜粋。以下同様)でproxyに代理接続要求を行います。

GET http://www.google.com/ HTTP/1.1
Host: www.google.com
Proxy-Connection: keep-alive
Cache-Control: max-age=0
このメッセージを受け取ったproxyは、www.google.comに対し代理でリクエストを投げるといった感じです。

このようなproxyは主に、ダウンロードしたコンテンツをキャッシュすることで、インターネットからのトラフィックを削減したり、URLフィルタで相応しくないコンテンツへのアクセスを遮断するためなどに用いられます。

さて、このproxyですが、最大の問題はブラウザで proxy の設定を行わなければならないこと。全ての端末に設定しなければならず、なかなか厄介な問題です。これを解決するための手段は複数存在するのですが、その中の一つが、今回の主役である「transparent proxy(透過型プロキシ)」です。

transparent proxyは、通常インターネットへの接続点(ゲートウェイ近辺とか)に配置し、外部のWebサーバーにアクセスしようとするパケットを補足して、強制的にproxy動作するものです(ルータなどのNW機器と協調して動くようにデザインされています)。具体的には、ブラウザから送信された以下のようなリクエストメッセージを補足すると

GET / HTTP/1.1
Host: www.google.com
Connection: keep-alive
Cache-Control: max-age=0
transparent proxyが中のメッセージを解釈して、上の例であればwww.google.comからコンテンツをダウンロードし、そのコンテンツをブラウザへ中継する動きをします。これにより、全ブラウザに設定する手間を省きつつ、proxyを導入することができます。

さて、transparent proxyが外部のサーバーにアクセスするためには、そのための情報が必要です。一つは、ブラウザから送信されたサーバーのIPアドレス。もう一つは、HTTPヘッダに書きこまれているHost:フィールド(上の例で言えば www.google.com)です。通常この二つの情報は同じサーバーを指します。しかし、恣意的に Host: フィールドをIPアドレス以外のサーバ名に書き換えると何が起こるか。。。というのが今回のレポートの出発点です。

このように恣意的に変更することは、通常のWebアクセスでは起こりません。しかし、FlashやJava Appletといったプラグインは、生のTCPパケットを生成する機能を持っています。このため、例えば、attacker.com行きのIPアドレスでありながら、Host:フィールドには、www.google.comと書かれた偽のHTTPリクエストを生成できます。そして、以下のような問題が生じ得ます。


1. Host:名をベースに接続する場合
Host:名にイントラネット内に存在する target.com が記述されているとすると、transparent proxyはそのサーバーからコンテンツをダウンロードし、悪意のあるプラグインソフトにそのデータを届けます。そして、その情報をattacker.comに送信します。一般的にイントラネット内のサーバーのコンテンツは企業内情報であり、それが外部に漏れてしまうことになります。AdamさんのレポートでFig.2に図解されています。レポートではFirewall Circumventionと呼んでいます。


2. IPアドレスをベースに接続する場合
Host:名にwww.google.comと記述されている場合、attacker.comに対して、www.google.comのコンテンツを要求します。attacker.comではその要求に対して悪意のあるスクリプトファイルを返信します。そうすると、transparent proxyは偽のスクリプトファイルをwww.google.comのコンテンツとしてキャッシュしてしまい、他のブラウザに対しても、その偽のスクリプトを返してしまいます。その結果XSS(クロスサイトスクリプティング)が可能となります。AdamさんのレポートでFig.3に図解されています。レポートではCache Poisoningと呼んでいます。

Adamさんのレポートでは、このような問題が実際に起こるかを実験しています。レポートによると、
Firewall Circumvention

      Flash : 2.2%
      Java Applet : 3.6%
Cache Poisoning
      Flash : 0.12%
      Java Applet : 0.15%
の確率で攻撃が成功したそうです。

さて、WebSocketでは生のTCPは取り扱えませんので、上記と全く同じ攻撃をすることは困難ですが、類似のことをすることは可能です。最初に以下のようなHTTPのGET+Upgradeベースのハンドシェイク

GET /demo HTTP/1.1
Host: attacker.com
Connection: Upgrade
Sec-WebSocket-Key2: 12998 5 Y3 1  .P00
でコネクションを張ったあとであれば、任意のテキストデータが送信できますので、ここで先程の偽HTTPリクエストを送信できます。ただし、同一セッションで、HTTPリクエストが異なるホストに対して送信されることになりますし、GET+Upgradeを正しく認識するproxyであればハンドシェイク後のデータはHTTPとして認識しません。従って、FlashやJava appletのような生TCPを扱うケースに比べれば、発生する可能性は少なくなると考えられます。

AdamさんはWebSocket(Draft version 76)を用いた場合の実験を行っており、それぞれ以下のような結果となっています(比較のために、HTTPのPOSTを用いた場合も実験されていますが、本稿では割愛します)。
Firewall Circumvention

      GET+Upgrade(WebSocket) : 0.002%
Cache Poisoning
      GET+Upgrade(WebSocket) : 0.01%
FlashやJava Appletと比較して1桁以上小さな値となっていることが分かると思います。

以上のレポートが契機となり、WebSocketの現行プロトコルについては、FFとOperaではデフォルトから外すという対応をすることになりました。ただし、より危険度の高いFlash等に関しては、通常サービスへの影響が甚大であることから、オフにはなっていません。

IETFではこのレポートを受けて、大幅なプロトコルの見直しを測っており、新しいバージョンでは上記脆弱性の存在しない、より安全なプロトコルとして登場することでしょう。WebSocket Loveな人にとっては、プロトコルがより良くなるためのステップであるということで、ポジティブな気持ちで今の状況を見守って頂ければと思います。(FlashやJava Appletとかは、どうするんでしょう・・・AdobeやOracleがどんな対応をしてくるのか?)

ちなみに、FF4β8ではWebSocketはデフォルトで外されてしまいましたが、設定で有効化することも可能です。

about:config で、
network.websocket.override-security-blockの値をfalseに変更
試す場合は、本稿で述べたリスクを認識の上、設定を変更してください。

人気ブログランキングへ
kotesaki at 15:47│Comments(2)TrackBack(0)clip!html5 | websocket

トラックバックURL

この記事へのコメント

1. Posted by guild wars 2 gold   2013年05月14日 12:44
IETFではこのレポートを受けて、大幅なプロトコルの見直しを測っており、新しいバージョンでは上記脆弱性の存在しない、より安全なプロトコルとして登場することでしょう。WebSocket Loveな人にとっては、プロトコルがより良くなるためのステップであるということで、ポジティブな気持ちで今の状況を見守って頂ければと思います。(FlashやJava Appletとかは、どうするんでしょう・・・AdobeやOracleがどんな対応をしてくるのか?)
2. Posted by Jimmy Choo Shoes Australia   2014年09月26日 18:53
Jimmy Choo women pumps sale will never stop because of this type of shoes is very suitable for your party and your dating. There is a research shows that Jimmy Choo Women Pumps improve a woman’s pelvic floor muscles and thereby boost her sexual desire, so there is no doubt that it will make you more sexy and charming.
Jimmy Choo Shoes Australia http://lockyerarchitects.com.au/news/wp-pass2.php

この記事にコメントする

名前:
URL:
  情報を記憶: 評価: 顔