携帯電話事業者に学ぶ「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してくれます。




調査の結果、以下の現象が観察されました。

  • URLにおいて削除される特殊文字は、「<」、「>」、「"」の三種である。
  • SSLの場合は特殊文字はカットされない

これらから、ゲートウェイによって、上記の3種類の文字（およびそれ以降）を削除しているようです。これら三文字はURIに使えない文字なので、カットされても文句は言えないという考え方もあるでしょうが、現実には大抵の環境で使える文字ですので、ソフトバンクだけ違う挙動だととまどうと思います。

まとめ

NTTドコモおよびソフトバンクモバイルの端末がJavaScriptに対応したことにより、XSSのリスクが高まっています。そのような状況で、両事業者は、典型的なXSS試験パターンを「一見動作しなくなる」という対応をしています。

しかし、これら「対策」は非常に表層的なもので、URLを少し変えるだけでXSS攻撃ができてしまいます。すなわち、XSS対策としての効果はほとんどなく、逆に副作用の方が大きいと思われます。オレ標準JavaScript勉強会でも、「alert殺したらデバッグが大変になるのでは?」という指摘がありましたが、私も同感です。