Hatena::ブログ(Diary)

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

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

2009-11-17

[][]P-07AでもJavaScriptが再開され、あらたな制限がみつかった P-07AでもJavaScriptが再開され、あらたな制限がみつかったを含むブックマーク

i-mode2.0は前途多難 - ockeghem(徳丸浩)の日記にて報告したように、ドコモiモードブラウザ2.0のJavaScript機能が5/28に停止されていたが、本日ケータイアップデートが準備されたので、深夜3時まで待たずに即座にアップデートを実行した。そして、JavaScriptが復活していることを確認した。

iモードブラウザ2.0のJavaScript « mpw.jp管理人のBlogで報告されているように、alert関数や、setRequestHeaderメソッドが無効化されていることを確認した。関数自体は削除されていないのだが、実行しても何もおこらない状態になっている。alertを無効化した理由は理解に苦しむが、setRequestHeaderを無効化したのは、携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性で指摘したような危険性を避けるためかもしれない。だが、setRequestHeaderを無効化したことで、あらたなリスクが生じるのだがそれについては稿を改めて報告したい。

JavaScriptの機能制限はそれだけではないようだ。現在忙しいので網羅的な調査はできないが、現時点で気づいた点として、XMLHttpRequestがSame origin Policyすなわちドメインの制約を受けるだけでなく、ディレクトリの制約も受けるようだ。具体的には、XMLHttpRequestが記述されたコンテンツのディレクトリと同じか、そのサブディレクトリのデータのみ読み込める。ディレクトリをさかのぼるようなリクエストはエラーになる。

私がこの現象に気づいたのは、以下のようなテストをしていてのことだ。http://example.jp/i/5.html (ホスト名は仮のもの)からhttp://example.jp/cgi-bin/dump.cgi を呼び出して、HTTPリクエストヘッダを調べようとしていたが、リクエストが発行されていない。試行錯誤の結果、同じコンテンツをhttp://example.jp/6.htmlに配置したら呼び出すことができた。また、http://example.jp/i/5.htmlからhttp://example.jp/i/test.txt は呼び出すことができた。

上記の実験から、P-07Aの(恐らくは、iモードブラウザ2.0の)XMLHttpRequestは、ディレクトリの制限が掛けられており、親ディレクトリにさかのぼるディレクトリは読み込めないと結論づけた。だが、なぜ。

本日公開された 再考・ケータイWebのセキュリティ(1):「PCでは見えないはず」に頼ることの危険性 (1/3) - @ITの2ページ目で、私は次のように書いた。

ケータイブラウザではHTMLソースを表示できないことを理由として、ケータイWebは、PC用の一般サイトよりも安全性が高いと思っている方がいますが、これは誤解であり【中略】その理由は、本来見えないはずのHTMLソースが閲覧できる場合があるからです。

【中略】

このほか、クロスサイトスクリプティングXSS脆弱性が当該サイトに存在すると、HTMLソースの一部あるいは全部が閲覧される可能性があります。特に、ケータイJavaScriptが利用できるようになると、サイトの1個所でもXSS脆弱性があれば、任意のページのHTMLを閲覧できるようになります。

http://www.atmarkit.co.jp/fsecurity/rensai/keitaiweb01/keitaiweb02.html

上記は、通常のJavaScriptでは正しい指摘なのだが、本日分かったiモードブラウザ2.0の新たな制約により、少し訂正が必要となった。「任意のページ」のHTMLではなく、「XSSの存在するページのディレクトリとサブディレクトリ」のHTMLのみが読み込める。

しかし、これがiモードブラウザ2.0にて、XMLHttpRequestディレクトリ制限がかけられた理由かどうかは分からない。

先に紹介した 再考・ケータイWebのセキュリティ(1):「PCでは見えないはず」に頼ることの危険性 (1/3) - @ITにも書いたように、ケータイWebの安全性は、クローズドなネットワークと携帯端末の機能制限に依存している部分がかなりある。だから、JavaScriptにも制限を掛けざるを得ないというのは理解できることだ。だが、その制限の範囲や方法には疑問があるし、どのような制限を掛けたかは、NTTドコモのサイトには掲載されていないようだ。これはサイト開発者にとっては不便だろう。私自身、XMLHttpRequestの非常に簡単なサンプルが動かなくて首をひねった。制限はある程度やむを得ないとして、NTTドコモには、もっと情報公開をしていただきたいと希望する。

追記(2009/11/18)

try〜catchで「親ディレクトリをGETした際のエラー」を捕捉すると、「Error: operation is inhibited」となりますので、やはり明確に禁止されているとみるべきでしょう。

また、KCCSにて「ケータイWebセキュリティ対策セミナー」を開催しておりますので、上記のような話も含めた最新の話題を提供したいと思います。あいにく3回のうち、1回目は終了、2回目は明日で申し込みは締め切っておりますが、第3回は12月10日(木) ですので、興味のある方はお申し込み下さい

ナカニシナカニシ 2009/11/20 18:41 昨日セミナーにてSoftBankのJavaScriptはどうですか?と質問した者です。その節はお世話になりました。
私のほうで932SHの実機にてXMLHttpRequestのリクエストヘッダの追加を行ってみたところ、
流石にx-jphone-uidは偽装することはできませんでしたが、docomo、au用のx-dcmguidとx-up-subnoを送信することができました。
User-Agentとあわせて端末識別IDのチェックを行っていればさほど脅威ではないかもしれませんが、この辺のチェックが甘いと問題になる可能性がありますね。
実はdocomoよりSoftBankのJavaScriptほうが、色々できすぎて脅威かもしれません。
他には
・リファラは送られてこない。Refererという名前のヘッダは追加不可
・Cookieという名前でヘッダの送信が可能(Cookieが無い時に試しました)

何かのお役に立てればと思います。

ockeghemockeghem 2009/11/21 00:49 ナカニシさん、こんばん。セミナーにお越し頂きありがとうございました。
あれから私も調べてみたのですが、Yahoo!ケータイでJavaScriptに対応したという情報はないのですが、ひょっとしてPCサイトブラウザの方ではありませんか? PCサイトブラウザであれば、Yahoo!ケータイとはIPアドレスが異なるので、PCブラウザ扱いということになると思います。
端末(ブラウザ)側のIPアドレスを調べて頂き、http://creation.mb.softbank.jp/web/web_ip.html にて、Yahoo!ケータイ側に属するIPか、PCサイトブラウザ側かをご確認いただけないでしょうか。Yahoo!ケータイ側であれば、大きな脅威になり得ると思います。

ナカニシナカニシ 2009/11/24 09:34 先日試した時のIPアドレスを調べてみましたところ、上記のページに記載されているIPアドレス帯域内でしたので、
やはり携帯サイトブラウザでアクセスされているかと思います。ブラウザの設定にもスクリプトの有効/無効の設定があります。
私の記憶している限りでは、SoftBank携帯のJavaScriptはキャリアがSoftBankになってすぐの3G端末から動いていたと思います。
その頃はアラートくらいで、XMLHttpRequestは動かなかったと思います。
確認している機種がシャープ・パナソニックの2機種だけなのでなんともいえませんが、動く機種は確かにあります。

ockeghemockeghem 2009/11/25 08:02 ナカニシさん、わざわざ調べて頂きありがとうございました。
私も、932SHを購入して調べ始めました。たしかにナカニシさんに言われるとおりです。
調べたことについては、機会を見て発表したいと思います。

 | 
Google