■

■GoogleサイトにXSS脆弱性、セキュリティ企業の指摘で修正(エンコーディング変更によるXSS攻撃)

UTF-7のお話し

2006-01-26追記

2004年11月において、既にこの種の危険性を指摘している文献がありました。svgばなしですけれど精神は同じです。

2006-01-26追記終わり

UTF-7を使ったのですね。セキュリティ企業の指摘の一端は以下のコードでわかります。

<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7">
</HEAD>
+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-

即確認したければ下記にTESTページがあります。IEとFirefoxとOperaで試しました。

上記TESTページでは3大ブラウザともにJavaScriptが起動されています。スクリプト部分はUTF-7で書いてありますので、XSS防止のフィルターをすり抜けるかも知れません。さて、IEでは、エンコードが自動選択であると、HTMLのファイルの最初の4096文字を読んでエンコード方式を機械的に推定するとのこと。上記のサンプルではその推定の様子は完璧には窺い知ることは出来ませんが。

ちょっと疑問なのですが、charsetってそもそもサーバからHTTP応答ヘッダの"Content-Type"フィールド中の"charset"に指示して提供すべきものなんでしょう？meta要素で念のために補足してあげるのは良いとして。今回Googleではどうだったのかなあ。原報告者のレポートではIEのみが危険だったと読めるのだけれど。

便利すぎるブラウザも困ったものだなあ。

ISO-2022-JPからShift_JIS,EUC-JPのお話

文字化けしている画面表示で、ISO-2022-JPからShift_JISにエンコードを変更するとスクリプトが発動するサンプルをid:hasegawayosukeさんがお作りになっています。

サーバ側でまず、HTTP応答ヘッダでcharsetをしっかり出して、ついでにHTMLファイル中でもmeta要素でcharsetをしっかり記述していていったとして…そういうブログなりダイアリなりのコメントからエンコード変更を行われるパターンってあんまりないような気もしますが、それでもサイト管理者さんはこれを機会に念のために気をつけたほうが良いでしょうね。

気になるコメント on スラッシュドットジャパン

この問題に関してはFirefoxのほうが危険な面もあります。 Internet Explorerは、UTF-16、UTF-7、ISO-2022-JPなどの「危険」なエンコーディング(1バイトの0〜0x7f以外のものがASCIIと解釈されうるエンコーディング)はユーザーの指定では選択できないようになっています。 まあタレコミのようなUTF-7っぽいものをUTF-7と勝手に判別させる攻撃があるし親コメントのようなShift_JISに変えると発動するトラップも作れるのでIEなら安心なわけでは決してありませんが。

うお？ほんとうだ。知らなかったし目が覚めました。なるほど。だからIEではISO-2022-JPに切り替えるメニューがなかったのね？下記より引用しました。

うお、こんなのもあった。

サーバーが文字列をISO-2022-JPとして処理してそれをクライアントがEUC-JPなどとして扱うとまずい、というのは考えられます。

<html>
<head>
aaa<script>/*bbb*/function msg(){alert('xss');}</script>
</head>
<body>
<button onclick="javascript:msg()">abc</button>
</body>
</html>

aaaをESC $ B、bbbをESC ( Bとバイナリエディタで置き換えると…

このスレッドは何度も読み直して仕様を確認しながら理解しなくては駄目だなあ…しっかし末端のエンドユーザは何をどうしたらよい？混乱中なりよ。

…確認用にこのソース、ちょっと変更したけれど、サーバにアップしてみました。htaccessで、HTPP応答ヘッダに以下のように出力。

Content-Type: text/html; charset=iso-2022-jp
Content-Language: ja

さらにmeta要素のhttp-equiv属性でcharset=ISO-2022-JPにしてあります。つまり万全を期しています。

どうもISO-2022-JPから他のエンコードに替えると？？？みたいな感じですね。以下、お試し版。表示すると最初はISO-2022-JPで文字化けしていますので適宜エンコードを変更して下さい。

エンコードXSSバグ追記(12/25)：ちょっとやばげな気がしてきました

まず、サーバー側でRFCに基づくきちっとした処理を行わなくてはいけない。可能な限りHTTP応答ヘッダでcharsetを明示する。さらに念のためにCGIを含み各HTML様出力ページではmeta要素を使ってcharsetを明示する。(サーバ側できちんと正しいcharset付の応答ヘッダを出している場合はむしろ省力可。meta要素でcharsetを明示する方法はいずれ標準で廃止になる可能性もある。)さらにエンドユーザには文字化けしたからといってウカツツにエンコーディング変更をしないでくださいと呼びかける。

それでもブラウザ側の実装の対応が難しければ、サーバ側の努力不足やウッカリなどが理由で危険性は残りうる。例えば今回のIEのように、自動的にUTF-7であると自動判定されてしまうと危ない。サーバサイドからなんらかの形でcharsetを示されれば良かったとのことだが…。あるいは、XSSで被害をこうむる特定のページに大きな文字化け対策ご案内を装ったフェイク画像を合法的に出力されてウッカリそれに従うと、というようなソーシャルアタックも考えられなくもない。このへんはあえてつっこまない方向で。

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4868

うーん。眺めているだけでため息が出てきました。HZってあるんですね。UTF-7と似たような気がしてきました。7 ビットで拡張ってのもアレでしょうか。始点アンカー側から終点側のcharsetをご指名するケースも考えられるのですねぇ。(私の手元では現在うまくいきませんが、昔は確かに出来たような気がします。このへん調査不足です。)これは大変に根深いような気がしてきました。なかなか直りきらんと思うのでブラウザ別にWorkaroundが欲しいかなあ。きちんと整理整頓できる頭が欲しいなあ。

関連資料(端的にまとまっていると思います)

Apacheな人は、今回の対策の為に念のため設定を見ることと思いますが、是非とも、上記の「AddDefaultCharset none の謎::RTFM」は読むといいと思います。この際ですから間違いを絶滅しましょう。(本日分の私の日記で、Content-Language: ja としてあるのは、今回の問題と無関係であるとわかります。なるほど。)…誤解が広まっているっぽいのでApacheな人以外でも間違っている人がいるかも。つか、間違えるのは日本人ばかりではないみたい。→WordPress ? UTF-8 charset in HTTP headers missing ≪ WordPress Support

meta要素のcharsetのお話し

HTMLって何？と思い始めた頃、私は魔術幻燈さんのファンになりました。HTMLでcharsetをどう考えたら良いのかについて以下のページが強く印象に残りました。歴史的文書なので内容が古いのかも知れませんがその精神が伺い知れます。最新の仕様書を確認すべきと思います。でもイイなあ。古(いにしえ)の頃がわかるって面白いです。

…サーバで出来るならなんとかしてあげてくださいっていう…Apacheならhttpd.conf や .htaccess で…そんな気がしたので魔術幻燈さんの上記文書をご紹介してみました。

ん〜。Googleさんって結局のところ今回はmeta要素でいったのねん。なにか他にメリットでもあったのかにゃ？