2013年5月の月例パッチ、MS13-037で修正された、Internet Explorerでエンコーディングの自動選択を強制的に起こせたバグについて書きます。 http://technet.microsoft.com/ja-jp/security/bulletin/ms13-037 このセキュリティ情報に組み込まれている多層防御についてマイクロソフトと協力してくださった Masato Kinugawa 氏 アドバイザリには問題に対する説明がありませんが、多層防御で修正されたのがこの問題です。 今回は、ざっと、報告書っぽく。 -------------------------------------------- 報告日： 2012年11月23日 問題の概要： IEで特定の方法でページを表示しようとすると、ページのエンコーディングの指定にかかわらず、ページに含まれるバイト値からブラウザ側で

リファラを使ったXSSの小ネタです。 今回取り上げるのは、ターゲット自身が、細工したページを経由することでつけられたリファラによって攻撃を受けるケースです。このような攻撃の場合は、現実に経由可能なページからでしか攻撃文字列を送りこむことができません。 例えば、以下のように、document.referrerをそのままdocument.write()しているページがあるとします。 http://vulnerabledoma.in/location/ リファラを書き出している部分でXSSできるでしょうか。 IEでは単純です。 IEはURLのクエリに、エンコードせずに「"<>」などを含めることができるので、これらを含むURLから、リファラを書き出しているページへ遷移させれば、XSSが起きます。 http://l0.cm/xss_referrer.html?<script>alert(1)</sc

ECMAScriptの仕様では、0x0A/0x0D以外にU+2028/2029の文字も改行とすることが明記されています。 これはあまり知られていないように思います。 以下はアラートを出します。 <script> //[U+2028]alert(1) </script> 知られていないだけでなく、知っていたとしても、スクリプトで文字列を処理するときに、U+2028/2029まで考慮する開発者がどれだけいるのかという話です。 実際、U+2028/2029を放り込むと文字列リテラル内にその文字が生のまま配置され、エラーが出るページは本当にたくさんあります。まあ、エラーがでるだけなら、大抵の場合大きな問題にはなりません。 ところが、U+2028/2029によってXSSが引き起こされてしまう場合というのを最近実際に見ました。 Googleのサービスで見つけた2つのケースを取り上げたいと思います。 ケ

昔自分が利用者だったサイトのセキュリティ問題(XSS)をいくつか報告していたのですが、おそらくそのリクエストを理由にインターネットが使えなくなりました。プロバイダに接続を止められたのです。 そのサイトで問題をみつけたとき、サービス提供者側の反応を示す兆候がありました。 問題を発見後、しばらくしてアクセスしようとすると、アクセスを拒否されたからです。 サービス提供者には問題を報告し、アクセス拒否についても、一応、今報告してる通りこれは攻撃ではないので誤解なきようよろしくとメール連絡したところ、問題は修正されました。 これで真意は伝わり、アクセスと関連付けられ、アクセス拒否に対する誤解も解決しただろうと思ったのですが、その後急にインターネットが使えない事態にまでなるとはだれが予想できたでしょうか…。(今は携帯の回線を使っています) プロバイダから書面が届き、書面には問題の報告時とほぼ同じ日付に

Twitterは2010年から、年ごとにTwitterのサービスのセキュリティ問題の報告者のリストを掲載しています。以下がそのページです。 https://twitter.com/about/security 幸運にも、僕は毎年載ることができているので、2013年も早速載ってやろうじゃないかということで頑張って脆弱性を探しました。結果はページを見てもらえばわかると思いますが、なんとかみつけることができました。今回みつけた問題がどんな問題だったかを書きたいと思います。2つあります。 1. analytics.twitter.com のXSS analytics.twitter.comは、Twitterが提供するサイトオーナーのための解析ツール、だそうです。こんな具合に、ログインページのパラメータでエンコーディング処理に起因するXSSがありました。 XSSベクタに関して特に面白いことはないので

今月まだ一度もブログを更新してないので、とりあえず小ネタを。 GoogleのTranslator Toolkitという、オンラインで共同でドキュメントの翻訳作業ができるツールに存在した、Googleにログイン中のユーザーのメールアドレスを攻撃者に知らせてしまう問題について書きます。 Translator Toolkitは、共同で翻訳作業をしたい人のメールアドレスを指定し、招待することで、アクセス可能な人を制限しながら翻訳作業をすることができるツールです。 アクセスを許可していない人から翻訳ドキュメントのURLにアクセスされても、以下のように、アクセス許可が与えられていないというメッセージが現れ、適切に閲覧制限できているのがわかります。 ところが一方、 victim.masatokinugawa がこのエラーメッセージを見ているとき、翻訳ドキュメントのオーナーの画面には以下のように表示されて

Safari 5.1.7で発見し、Safari 6で修正された、feed:// URLのUXSSについて書きます。 http://support.apple.com/kb/HT5400 Safari 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 cross-site scripting issue existed in the handling of feed:// URLs. This update removes handling of feed:// URLs. CVE-ID CVE-2012-0678 :

安定版Opera 12.10で修正されているのを確認したので書きます。 ベンダは悪用は難しいとして、これをノーマルバグとして扱いましたが、修正前はcharset指定がないページやEUC-TWエンコーディングのページでXSSを引き起こす可能性がありました。 これを見つけた経緯から話すと、僕は以前から、ブラウザがサポートするエンコーディングのページで、「0x22」「0x26」「0x27」「0x3C」「0x3E」「0x5C」("&'<>\)などの特殊な文字がマップされているバイト値を除いた上で、ランダムにバイト列を表示させて、別のバイト列で「"&'<>\」が現れないかチェックするというような、ブラウザのセキュリティバグを発見するためのテストを行っていました。これにより、OperaのEUC-TWで「"<>」などを検出し、この問題を発見しました。 実はこの手法で他のブラウザでもいくつかの問題を検出し

今日は、 そもそもホストの前に任意の文字列を置けるということを忘れていると、うっかりそこにJavaScriptで触ってしまった時に問題が起こる場合があるよね、という話をします。 以前紹介したlocation.hrefの問題に似ていますが、今回取り上げているのは文字列がデコードされることにより起きうる問題ではなく、文字列が取得されることで起きうる問題についてです。 まずは、様々な形でJavaScriptでURLを確認できるスーパーウェブサイトを用意致しましたので、ホストの前に文字列を含むURLが、どの値で取得されているかを実際に見てみてください。 http://user:pass@vulnerabledoma.in/location/ (※このページはURLをそのまま書きだしているため、当然DOM based XSSがありますが 、その挙動も含めて確認できるようにする目的があるので、あえてそ

第3弾です。第1弾はこちら。第2弾はこちら。 ターゲットはIEのXSSフィルターです。 今回のバイパスは、本来作成できてはならないjavascript:スキームのリンクをIEのXSSフィルターの挙動を利用して作成するという方法で行います。 いきなりですが、発見した方法はこれです。 http://vulnerabledoma.in/xssable?q=%22%3Ca%20href%3Djavascript%26.x3A%3Balert%26%28x28%3B1%26%29x29%3B//=%3Exxx 何がどうしてここにたどりついたのか、順に見ていきます。 IEは「<a href="javascript:alert(1)">xxx」のような文字列がクエリ文字列にあり、その文字列がページ中に出力されるなら、その出力の一部を書き換え、XSSを遮断しようとします。 http://vulnerabl

(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無利息キャッシング – キャッシ

夏ということで、怖い話をします。 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

FirefoxのアドオンであるNoScriptに備わっているXSS防止機能の、これまでに僕が報告した、対策された迂回方法を公開します。 1. v2.3.2rc2で修正 http://vulnerabledoma.in/char_test?charset=iso-2022-jp&body=%3Cifr%1B%28Jame%20o%1B%28Jnload=aler%1B%28Jt%281%29%3E ISO-2022-JPでエンコードされたページまたは自動選択でISO-2022-JPが選択されたページで、NoScriptが反応する文字列中にISO-2022-JPで無視されるバイト列を挟むことで検出を回避できました。 2. v2.3.2rc3で修正 http://l0.cm/noscript/ 単純にイベントハンドラの検出のバグです。URL中に()が入ると弾かれるので、location.href

マイクロソフト セキュリティ情報 MS12-023 - 緊急 : Internet Explorer 用の累積的なセキュリティ更新プログラム (2675157) http://technet.microsoft.com/ja-jp/security/bulletin/ms12-023 このセキュリティ情報に組み込まれている多層防御についてマイクロソフトと協力してくださった Masato Kinugawa 氏 2012年4月のMicrosoftの月例アップデートに含まれる、MS12-023で修正されたこの件について書きます。 Internet Explorer 9では、悪意ある者に誘導されてアドレスバーで不本意なJavaScriptを実行してしまうこと(self-XSS)を防止するために、「javascript:alert(1)」や「vbscript:alert(1)」のような、スクリプトを

UTF-16をContent Security Policy(以下CSP)の迂回に使ってみようという記事です。ほとんどの場合で問題になりませんが場合によってはこうもできるかもしれないよね、ということを示すために書きます。真面目に読まないでください。 シンプルな迂回方法 やろうとしていることを理解しやすくするために、先にシンプルな迂回方法を示します。 CSPで選択的に外部ドメインのJavaScriptの読み込みを許可しているような場合、読み込みを許可したドメインにscriptタグのsrcとしてエラーのないように悪意のあるスクリプトを書けてしまう箇所があれば、当然XSSがあった時にCSPを迂回して攻撃することができてしまいます。 僕が攻撃しようと思ったら真っ先に狙いに行くのはJSONPのcallback関数名です。具体的に例を示すと、 CSPを導入したサイトで、外部サイトのcsp.exampl

第2弾です。第1弾はこちら。今回はアプローチがちょっと違います。 無視されるバイトの利用 タグ中に挿入されても無視されるバイトというのがあります。有名なのはIEの「0x00」のスルー(<scr[0x00]ipt>alert(1)</sc[0x00]ript>が動いてしまう)ですが、他にもブラウザと文字エンコーディングによっては無視されるバイトがあります。今回はこれをXSS保護機能のバイパスに使用します。 2か月ほど前に、個人的に無視されるバイトを各ブラウザ・各文字エンコーディングごとに網羅的に調査してみました。んで、この結果を掲載しようと思ったんですが、自分用にまとめたもので汚いし、まだいろいろ調査中の部分もあるのでそれはもうちょっとあとにします。結構たくさんあります。 IEのXSSフィルターをバイパスする IEのXSSフィルターはさすがにIEが「0x00」を無視することを知っています。

Googleに存在したメールアドレスを窃取できた問題について書きます。これは2011年1月30日に報告し、報告後数日以内に修正された問題です。 こんなページがありました。 http://example.google.com/redirect?continue=http://example.google.com/xyz <meta http-equiv="refresh" content="0;url=&#39;http://example.google.com/xyz&#39;"> <script> location.replace("http://example.google.com/xyz") </script> continueというパラメータに指定されたURLをmetaタグとlocation.replace()にそれぞれ入れて、JavaScriptの有効/無効の設定に関わらずリダイ

Chrome Stable Release http://googlechromereleases.blogspot.com/2011/10/chrome-stable-release.html [95374] Low CVE-2011-3879: Avoid redirect to chrome scheme URIs. Credit to Masato Kinugawa. 去年の9月に報告し10月に修正された、Google Chromeの(一応)セキュリティバグです。 Google Chromeでは、「chrome:」という独自のスキームでブラウザの設定や履歴の閲覧などができるページが用意されています。通常このスキームにリダイレクトさせたりリンクしたりすることはできません。 ですから例えば、 <script>location.href="chrome://about/"</script