ブラウザのXSS保護機能をバイパスする(11)

勝手な使命感に駆られて書く脆弱性"&'<<>\ Advent Calendar 2016 7日目の記事、3回目の登場です。

今日も相変わらずXSSフィルターをバイパスします。
今回は先月(2016年11月)の更新で塞がれたIEのXSSフィルターのバイパスを簡単に紹介します。

=================================
追記:
Windows 8.1だとまだ動くのを確認しました。
どうも、塞がれたのはWindows 10だけみたいです。ご活用ください！
=================================

前回の記事に引き続き、今回も文字列リテラルで起こるバイパスです。
前回は任意のスクリプト実行とまではいかない部分的なバイパスでしたが、今回のは完全かつとてもシンプルに空いていたバイパスです。こちらです。

https://vulnerabledoma.in/xss_js?q="i\u006E+alert(1)// (X-XSS-Protection:0 にして試すにはこちら)

<script>var q=""i\u006E alert(1)//"</script>

inをUnicodeエスケープして、i\u006Eと表記することでバイパスできていました。

モダンなブラウザでは、予約語をUnicodeエスケープすることは禁止されていますが、 IEでは禁止されておらず、inと同じ扱いになります。

この件は、@Jxck_さん主催の次世代Webカンファレンスに参加中、一週間後に迫るCODE BLUEの資料を、最初に作ったものが諸事情で公開できなくなってしまっため、一からいそいそと作っていたとき、突然気付いたものでした。その時のツイートです：

#nextwebconf に参加中ですが突然新しいXSSフィルターのバイパス手法を思いつきました。

— Masato Kinugawa (@kinugawamasato) 2015年10月18日

XSSフィルターの正規表現を眺めていたところ、他の文字列リテラル中で起きる禁止文字列はUnicodeエスケープが一緒に記述されているのに対し、inだけUnicodeエスケープが無いことに気付き、試したところすんなり動いたというかんじでした。

ちなみに、MicrosoftはこれまでXSSフィルターのバイパスを脆弱性という扱いで修正していましたが、最近方針の変更があり、今後はセキュリティ修正扱いにしないことにしたとのことで、11月の更新プログラムを適用するとバイパスは塞がれるものの、アドバイザリの中ではこの変更については説明されていません。なお、謝辞には僕の名前がありますが、これら(CVE-2016-7227 と CVE-2016-7239)はバイパスとは別のバグです。こちらもまた機会を改めて紹介したいと思います。

バイパスは脆弱性ではないというのはその通りだと思いますし、もともとそう考えていたので、いちいち許可をとらずにブログに書いていましたが、今後、報告中のものも含め公開してもよいという回答を正式に頂いたので、また遠慮なくブログに書かせてもらいます。

以上、脆弱性"&'<<>\ Advent Calendar 2016 7日目の記事でした。
明日も書く人が決まっていないみたいなので、どなたか書いてください！