URLのUXSSについて書きます。以前ブログに書いたように、Safariには、URLのホストの前の認証情報文字列をlocation.hrefで取得するとき、中身がパーセントデコードされて取得されるという問題がありました。僕は、この挙動はブラウザの問題だと思ったのですが、Appleは(最終的には修正したものの一度は)「修正する予定はない」という返事をしてきました。実際にこの挙動で問題が起きる部分をみつけて、ブラウザ側の修正の必要性を示してやろうということで、いろいろなページを@付きURLでアクセスしてまわりました。そのときに発見したのがこの問題です。どんな問題かSafariでは、フィードのURLにアクセスすると、http://masatokinugawa.l0.cm/feeds/posts/defaultから、feed://masatokinugawa.l0.cm/feeds/posts/defaultのような、先頭をhttp://からfeed://に変えたURLにリダイレクトし、Safariが独自に生成したフィード用のページを表示します。ちなみにこのURLは僕のブログのフィードのURLです。URLを、@付きURLにして、少し細工してアクセスしてみると、奇妙なことがおきます。feed://www.apple.com%2Fpr%2Ffeeds%2Fpr.rss%3F@masatokinugawa.l0.cm/feeds/posts/defaultmasatokinugawa.l0.cmなのに、@の前に書かれたURLの、Appleのフィードが表示されています。試しにここで、アドレスバーで「javascript:alert(document.domain)」とすると、「masatokinugawa.l0.cm」と表示され、masatokinugawa.l0.cm上でwww.apple.comのフィードが展開されていることがはっきりと確認できます。通信を監視してみると、以下のリソースをとってきています。URLでは、@以前の文字列をデコードしたURLを、そのページのフィードとして読み込んでしまうみたいです。これはつまり、ターゲットのサイトに読み込ませる外部のフィードにスクリプトを書くことができれば、XSSが可能ということになります。Safariではフィード用ページでのJavaScriptの実行を、スクリプトが実行可能な文字列を除去する形で制限しています。一部適切に制限できていない文字列がありました。URL上に設定できてしまいます。/></a></svg>さあ、これを含んだフィードをさっきのURLに流し込んでみましょう。URLに直接アクセスする場合は@付きURLでも警告が出ません。URLで表示させることができます。以下のように、どんなサイトでもXSSのターゲットにできるということです。feed://l0.cm%2Fsafari_uxss.rss%3F@www.google.comfeed://l0.cm%2Fsafari_uxss.rss%3F@www.facebook.comfeed://l0.cm%2Fsafari_uxss.rss%3F@twitter.comMacでSafariのアップデートをしていない方は、早急に最新版にアップデートしましょう。Windows版ではこのブログ投稿現在、アップデートが提供されていません。6の公開から4ヵ月が経とうとしているのに、何の動きもないので、もはやこれ以上開発を継続する気はないと思われます。5.1.7にはこれ以外にも複数の脆弱性の存在が確認されており、JVNもWindowsユーザーはSafariの使用をやめるよう勧告しています。WindowsのSafariユーザーは、使用をやめるよう、僕からもお勧めしたいと思います。mキーがmixiのロゴ仕様になっていてかわいいです。↓ロゴ入りバッグとロゴ入りカラビナも頂きました。嬉しいです!ありがとうございます。mixiは"過去の教訓"からか、かなりセキュリティに配慮した作りができていると思います。mixiでデコメ付き日記が書けるようになった時に、一部のHTMLタグが日記中で使用できるよう変更されたことがありました。この時XSSを作りこんでるんじゃないかと思ってみてみましたが、使用可能なタグが厳密に制限されており、かなり慎重にやっているなと感じました。今のところこの部分については特に問題をみつけていません。それでも他の部分についても全く脆弱性がない訳ではありません。XSSやオープンリダイレクタ、変わったところでは、他人の日記のコメントを削除できてしまう問題、有料コンテンツを無料で取得できてしまう問題などを過去に報告したことがあります。mixi様、この度は送って頂きありがとうございました。何かくださるという方はご一報ください。次のお届け物をお待ちしております。12.10で修正されているのを確認したので書きます。ベンダは悪用は難しいとして、これをノーマルバグとして扱いましたが、修正前はcharset指定がないページやEUC-TWエンコーディングのページでXSSを引き起こす可能性がありました。これを見つけた経緯から話すと、僕は以前から、ブラウザがサポートするエンコーディングのページで、「0x22」「0x26」「0x27」「0x3C」「0x3E」「0x5C」("&'<>\)などの特殊な文字がマップされているバイト値を除いた上で、ランダムにバイト列を表示させて、別のバイト列で「"&'<>\」が現れないかチェックするというような、ブラウザのセキュリティバグを発見するためのテストを行っていました。これにより、OperaのEUC-TWで「"<>」などを検出し、この問題を発見しました。実はこの手法で他のブラウザでもいくつかの問題を検出していました。それらはどれも、ある固定のバイト列で、現れてはいけない文字が現れてしまうというもので、僕もそれを想定してやってた訳なんですが、このOperaのEUC-TWだけは、検出後に同じバイト列を使って再現させようとしてもなぜか一度は検出したはずの文字が現れず、うまくいきませんでした。調査を続けていくと、どうも特定のバイト列が、時折文字を変えつつ、ほぼランダムな文字を返してくるということがわかりました。そのバイト列周辺を並べたのがベンダへの報告時にも使った以下のページです。http://l0.cm/o_euc-tw_a1xxここの、0xA181-A1A0によくわからない値がくるのです。EUC-TWにおいて本来は使われないバイト列であるみたいなんですが、どうも処理が狂っているようです。(12.10では不正であるとしてU+FFFDが2つ現れます。)さらにみていくと、たまに目に見えて意味のある文字列が返ってきていることに気が付きました。これだけでどうみてもバグってるし、場所もはっきりしたのでもう十分バグ報告してもいいんですが、何度か「"&'<>\」を検出してる訳なので、セキュリティ上の脅威になるかどうかをちゃんと調べようと思ってさらにみていきました。すると、バイト列には、たまに、自分が表示しようとしているHTMLの内容を含んでいる場合があるということにも気が付きました。ページ下部に「<」(0x3C)を大量に並べたところ、以下のようになったことがありました。この時点で、このバイト列に、認証を済ましたページで表示された文字が含まれるなどすれば、情報が漏洩しうることになるので、セキュリティバグと言えるでしょう。僕はXSSがしたいのでまだ続けます。0x3C....と書いておけば「<」が得られそうです。実際何度かそのようにして試していると「<」が得られました。この方法で確かにXSSができることは確認しました。「<」のような問題のある文字を現れさせることはできても、確実に出現させる方法がわかりませんでした。このバイト列に一度「"&'<>\」などが現れても、何かの拍子に中身が変更されてしまう場合が頻繁にあることなどから、安定して攻撃に使う方法を見つけられずにいました。EUC-TWは、他のメジャーブラウザでもほとんどサポートされていないエンコーディングなので、ウェブページの表示にはまず使われていないのではないかと思います。そんな重箱の隅をつついて何の意味があるんだと思うかもしれませんが、Operaには、charset指定のないページをフレームに埋め込むと、親フレームの文字コード指定をクロスドメインでも継承するという挙動があるため、看過できません。(これはめんどうくさいWebセキュリティのp281にも書いてあります。12.02でこのページを見るとフレーム中にiso-2022-jpと表示されるはずです。この挙動は12.10では修正されているように思いますが、@masa141421356さんによるとまだ条件によっては継承するみたいです。これを利用すれば、EUC-TWで見ることを想定していないcharset指定がないページでも、ある程度バイト列を自由に出力できるなら、問題のバイト列を挿入してXSSを起こすことができます。攻撃は安定的にはできないものの、一応情報も漏洩するしXSSも可能なので、まぁセキュリティバグだろうと、このフレームによる継承の手法も含めて報告しました。Operaのベンダ的にはノーマルバグだそうです。Operaの脆弱性のCVE番号をゲットすれば、「5大ブラウザのCVE番号をゲットする」のアチーブメントをアンロックできるんですけど、なかなか難しいですね。