WebSocketがdisableにされた件、その2

先の記事参照

プロトコルレベルでセキュリティ問題となり、disableにされたWebSocket。
そしてその影響は、JavaのAppletやFlashにも波及します。

しかしですね。良く考えたんですが、これってやっぱりproxyが進んで対応しなきゃいけない問題だと思うんです。

まず、@toshirot さんからの情報参照。この問題は、CERTによって報告され、既知の問題であることが分かります。
また、WebSocketを用いたサービスを運営されているpusherappさんでも以下の記事があります。
http://blog.pusherapp.com/2010/12/9/it-s-not-websockets-it-s-your-broken-proxy

さて、既知の問題であるからと言って、WebSocketのプロトコルをそのままにしておくのがよい、とは言いません。しかしながら、これはWeb(HTTPやその周辺プロトコル)の問題だけでは済まないと思うんです。

今や、FireWallやProxyをこえるために、dst:80番ポートを用いて通信する専用クライアントはごまんといます。(例えばネットゲームやSkypeなどのVoIPアプリなど)
また、AndroidやiPhoneにおいてWi-Fi経由でネットワークを利用するアプリケーションもごまんと出てきています。

先の問題の本質は、

透過型プロキシ(transparent proxy)が中継している場合、そのコネクション上で、Hostフィールドを詐称し、HTTPに似せたパケットを送受信すると、透過型プロキシが誤動作を起こす or/and 間違ったORIGINのファイルをキャッシュする、ことがある

です。

とするとですよ。一般的なネットワークアプリケーションでTCP接続し、その上で似たようなことをすれば、まったく同じ影響を受けるわけです。
つまり。

1. iPhone App Storeとか、Android App Storeから無料アプリケーションをダウンロードした。
2. 無料アプリケーションが、外部サーバ(80番利用)にTCP接続する。
3. TCP接続したアプリケーションが、HTTPパケットに似せたパケットを送受信する。

この手順を踏むだけで、今回報告された攻撃が出来るわけです。

ブラウザ(+JS/Flashなど)でお手軽に、と言うわけにはいかないので、少しだけセキュリティリスクが低い、とは言えるものの、まぁ、iPhone AppとかAndroid Appとか、リリース時にここまで踏み込んで審査出来てるとは思えないので、やっぱりセキュリティリスク抱えたtransparent proxyは使わない方がいいよ(Fixされたtransparent proxyは別、ね)、と言う気がしますです。

ではでは。