Hatena::ブログ(Diary)

ockeghem(徳丸浩)の日記 このページをアンテナに追加 RSSフィード

[PR]WAFの導入はHASHコンサルティング
 | 

2010-07-26

携帯電話事業者に学ぶ「XSS対策」 携帯電話事業者に学ぶ「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>

f:id:ockeghem:20100726125316p:image:left


同じことをiモードブラウザ2.0で表示させると以下のようになります(P-07Aで検証)。

f:id:ockeghem:20100726130013j:image:left


見事にXSSが阻止されています…というのは早とちりで、iモードブラウザ2.0のJavaScript « mpw.jp管理人のBlogに報告されているように、iモードブラウザ2.0では、alert(やconfirm、prompt)は何もしない関数になっているのでした。このため、alert()の代わりに、document.write()を使うと、以下のようにCookieが表示されます。

f:id:ockeghem:20100726130628j:image:left


ソフトバンクに学ぶ「XSS対策」

こんどは、先ほどのalert版のURLソフトバンク端末で表示させると、やはりalertが動きません(932SHで検証)。ソフトバンクの端末ではalertは殺されていないはずなのに、不思議です。

f:id:ockeghem:20100726131024j:image:left


実はこれ、オレ標準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してくれます。

f:id:ockeghem:20100726131830j:image:left


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

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

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

まとめ

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

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

 | 
Google