■

■IEにおいてUS-ASCIIなエンコーディングでXSS発生？ このエントリーを含むブックマーク

US-ASCII な記述で、<,>,", のフィルタリングを回避可能かもの実証コード(IEのみが脆弱)

ちょっと古いハナシなのでしょうけれど。

原因はどこにあるのか

上記実例にてサーバからのHTTP応答ヘッダを見てみると。

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
ETag: W/"428-1150936271000"
Last-Modified: Thu, 22 Jun 2006 00:31:11 GMT
Content-Type: text/html
Content-Length: 428
Date: Sat, 24 Jun 2006 13:59:01 GMT

上記の応答には、特徴的なことがあります。 Content-Type: text/html; charset=ISO-8859-1 となっていないのですね。charsetは、本来はHTML文書の中で指定するものではなく、サーバがHTTPヘッダに付けるべきものです。また、万が一サーバからの指定がないときのために補うための、meta要素によるcharset記述もないようです。

このような場合に、IEは、エンコードとして、US-ASCIIを選択しているようです。HTMLを見るとmeta要素にcharset指定がしてありました。US-ASCIIです。実際に、先の実証コードを見たら、メニューバーから、表示メニュー→エンコードとみてやると、薄灰色でUS-ASCIIとなっています。薄灰色なのは、ユーザが自分であらかじめ選べないことを意味していて、IEが自分で決めましたということを示しています。

US-ASCII なエンコードにおいて、たとえば、16進のA2のキャラクターは、16進で22のキャラクター、" と等価になってしまっているようですね。8ビット目を落としてしまっています。こういう仕様なのでしょう。

webアプリなどのフィルタリングを回避して悪意ある記述を放り込むことが可能なのかもとか。

しかし、いまどきcharset指定もしないような環境ってあるのでしょうか。実際問題、脅威ではないような気が致します。それよりは、以下の日本産のほうが、ずっと私には怖いのですけれど。対処はブラウザ側にはたぶんIEだから無理なので、webアプリ側のフィルタリング手法が肝要になってくるからです。

ちょっと追記。えむけいさんに速攻で指摘されました。訂正をしました。ありがとうございます。どうやら、以下のさまざまなものを見ているうちに混乱したようです。てへ。

実際問題、もっと怖いしあまり知られていない

サーバ側の防御策として、統一見解的にはどのような対処が必要なのでしょうかねぇ？おっかねぇなぁとか思いますです。IEがなんとかしてくれるとは思えないし…

■How to make XmlHttpRequest calls to another server in your domain このエントリーを含むブックマーク

自分の配下にある同じドメインだけど異なるサーバにXmlHttpRequestしたいときにどうしたらよいのか

あとで読むためのメモ。凄く気になります。