2010-07-26
■携帯電話事業者に学ぶ「XSS対策」 
NTTドコモとソフトバンクモバイルは、フィーチャーフォン（いわゆるガラケー）にてJavaScriptの対応を始めています。JavaScriptに対応すると、クロスサイト・スクリプティング(XSS)脆弱性の懸念が高まりますが、両社は独自の手法によりXSS対策をしている（しようとしている）挙動が観測されましたので報告します。この内容は、オレ標準JavaScript勉強会でネタとして使ったものです。
NTTドコモに学ぶ「XSS対策」
まず、サンプルとして以下のようなXSS脆弱なスクリプトを用意します。
<?php session_start(); ?> <body> こんにちは<?php echo $_GET['p']; ?>さん </body>
これを以下のURLで起動すると、IE7では下図のような表示になります。
http://example.com/xss01.php?p=山田<script>alert(document.cookie);</script>
同じことをiモードブラウザ2.0で表示させると以下のようになります（P-07Aで検証）。
見事にXSSが阻止されています…というのは早とちりで、iモードブラウザ2.0のJavaScript « mpw.jp管理人のBlogに報告されているように、iモードブラウザ2.0では、alert（やconfirm、prompt）は何もしない関数になっているのでした。このため、alert()の代わりに、document.write()を使うと、以下のようにCookieが表示されます。
ソフトバンクに学ぶ「XSS対策」
こんどは、先ほどのalert版のURLをソフトバンク端末で表示させると、やはりalertが動きません（932SHで検証）。ソフトバンクの端末ではalertは殺されていないはずなのに、不思議です。
実はこれ、オレ標準JavaScript勉強会の準備中に見つけた現象で、しばらく悩みました。「ひょっとして、バンクさん、XSSフィルタを導入した?」、いやそんなはずは…
このときのWebサーバーのログを見ると以下のようになっています。
123.108.237.21 - - [26/Jul/2010:13:12:37 +0900] "GET /xss01.php?p=%8ER%93c HTTP/1.1" 200
「<」以降がすぱっと切られています。一種のサニタイジングというのでしょうか。なんか大胆な「対策」ですね。
でも、この「対策」、「<」や「>」をパーセントエンコードすると、以下のようにちゃんとXSSしてくれます。
調査の結果、以下の現象が観察されました。
これらから、ゲートウェイによって、上記の3種類の文字（およびそれ以降）を削除しているようです。これら三文字はURIに使えない文字なので、カットされても文句は言えないという考え方もあるでしょうが、現実には大抵の環境で使える文字ですので、ソフトバンクだけ違う挙動だととまどうと思います。
まとめ
NTTドコモおよびソフトバンクモバイルの端末がJavaScriptに対応したことにより、XSSのリスクが高まっています。そのような状況で、両事業者は、典型的なXSS試験パターンを「一見動作しなくなる」という対応をしています。
しかし、これら「対策」は非常に表層的なもので、URLを少し変えるだけでXSS攻撃ができてしまいます。すなわち、XSS対策としての効果はほとんどなく、逆に副作用の方が大きいと思われます。オレ標準JavaScript勉強会でも、「alert殺したらデバッグが大変になるのでは?」という指摘がありましたが、私も同感です。
[スーパースター] SUPERSTAR SUPERSTAR J174 SUP...
コクヨ カッターナイフ替刃（標準型）１０枚入- 251 http://b.hatena.ne.jp/hotentry
- 251 http://reader.livedoor.com/reader/
- 202 http://twitter.com/
- 104 http://b.hatena.ne.jp/hotentry/it
- 88 http://ke-tai.org/blog/2010/07/27/manabuxss/
- 84 http://d.hatena.ne.jp/
- 79 http://www.google.co.jp/reader/view/
- 79 http://www.google.com/reader/view/
- 59 http://ke-tai.org/
- 54 http://b.hatena.ne.jp/entry/d.hatena.ne.jp/ockeghem/20100726/p1
