Masato Kinugawa Security Blog: ブラウザのXSS保護機能をバイパスする(5)
先月に続いてIEのXSSフィルターをバイパスする記事です。 今回は、ブラウザのXSS保護機能をバイパスする(2) の応用を思いついたので紹介したいと思います。 ブラウザのXSS保護機能をバイパスする(2) で紹介した手法は、シンプルな反射型XSSが存在するとき、以下のような条件でIEのXSSフィルターをバイパスできることを示すものでした。 ・レスポンスヘッダにX-XSS-Protection:1 または X-XSS-Protectionの指定なし ・Content-Typeレスポンスヘッダにcharset指定がない ・<meta http-equiv=> でcharset指定をしている この記事を書いた段階では、<meta http-equiv=> でcharset指定をしている場合しかバイパスできないと考えていましたが、最近、<meta charset=> でcharset指定がある場合
Masato Kinugawa Security Blog: たぶんXSSが理由でインターネットがとまった
昔自分が利用者だったサイトのセキュリティ問題(XSS)をいくつか報告していたのですが、おそらくそのリクエストを理由にインターネットが使えなくなりました。プロバイダに接続を止められたのです。 そのサイトで問題をみつけたとき、サービス提供者側の反応を示す兆候がありました。 問題を発見後、しばらくしてアクセスしようとすると、アクセスを拒否されたからです。 サービス提供者には問題を報告し、アクセス拒否についても、一応、今報告してる通りこれは攻撃ではないので誤解なきようよろしくとメール連絡したところ、問題は修正されました。 これで真意は伝わり、アクセスと関連付けられ、アクセス拒否に対する誤解も解決しただろうと思ったのですが、その後急にインターネットが使えない事態にまでなるとはだれが予想できたでしょうか…。(今は携帯の回線を使っています) プロバイダから書面が届き、書面には問題の報告時とほぼ同じ日付に
Masato Kinugawa Security Blog: 各ブラウザがサポートするcharsetのリスト
メジャーブラウザがサポートするcharsetのリストを個人的に調べてまとめたので公開します。 正式名とエイリアスのリスト http://l0.cm/encodings/list/ 表にしたもの http://l0.cm/encodings/table/ charsetの発見は以下のようにして行いました。 1. charsetとして認識してくれそうな文字列をウェブからかき集める。 2. Content-Typeヘッダのcharsetの値に、集めた文字列から1つ選んで指定し、bobyには、<meta charset="iso-2022-jp">を含んだページを作る。 3. 2で作ったページをフレームに読み込み、親フレームからJavaScriptでフレームに設定されたcharsetの値を読み取る。 4. 取得されたcharsetの値により以下のAかBの判断/処理をする。 A. iso-2022-
Masato Kinugawa Security Blog: Twitterの脆弱性 2013
Twitterは2010年から、年ごとにTwitterのサービスのセキュリティ問題の報告者のリストを掲載しています。以下がそのページです。 https://twitter.com/about/security 幸運にも、僕は毎年載ることができているので、2013年も早速載ってやろうじゃないかということで頑張って脆弱性を探しました。結果はページを見てもらえばわかると思いますが、なんとかみつけることができました。今回みつけた問題がどんな問題だったかを書きたいと思います。2つあります。 1. analytics.twitter.com のXSS analytics.twitter.comは、Twitterが提供するサイトオーナーのための解析ツール、だそうです。こんな具合に、ログインページのパラメータでエンコーディング処理に起因するXSSがありました。 XSSベクタに関して特に面白いことはないので
Masato Kinugawa Security Blog: エンコーディングの切り替えによるSelf-XSSを考える
Shift_JISにすると、UTF-8でひらがなの「く」を構成する「0xE3818F」の先頭2バイトが、まず「縺(0xE381)」という文字と解釈され、残った「0x8F」が、後続の、二重引用符のエスケープシーケンスである「\(0x5C)」と１つの文字、「十(0x8F5C)」を作ってしまうのです。これにより、エスケープシーケンスがなくなった二重引用符は、そこで文字列リテラルを閉じることになります。こうして、その後ろに書かれたアラートが動いてしまうという訳です。 つまりこれは、攻撃者に誘導され、ユーザー自身が文字エンコーディングを切り替えた場合、本来XSSがないページでもXSSが起こせる場合があるということです。 IE以外のブラウザは、親フレームのエンコーディングを変更した場合、クロスドメインでも子フレームのエンコーディングまで変更するので、こんな誘導の仕方もできます。 http://l0.c
Masato Kinugawa Security Blog: CVE-2012-0678: Safariのfeed:// URLのUXSS
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 :
Masato Kinugawa Security Blog: ホストの前に文字が置けることを忘れるな
今日は、 そもそもホストの前に任意の文字列を置けるということを忘れていると、うっかりそこにJavaScriptで触ってしまった時に問題が起こる場合があるよね、という話をします。 以前紹介したlocation.hrefの問題に似ていますが、今回取り上げているのは文字列がデコードされることにより起きうる問題ではなく、文字列が取得されることで起きうる問題についてです。 まずは、様々な形でJavaScriptでURLを確認できるスーパーウェブサイトを用意致しましたので、ホストの前に文字列を含むURLが、どの値で取得されているかを実際に見てみてください。 http://user:pass@vulnerabledoma.in/location/ (※このページはURLをそのまま書きだしているため、当然DOM based XSSがありますが 、その挙動も含めて確認できるようにする目的があるので、あえてそ
Masato Kinugawa Security Blog: ブラウザのXSS保護機能をバイパスする(3)
第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
Masato Kinugawa Security Blog: 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無利息キャッシング – キャッシ
Masato Kinugawa Security Blog: 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
Masato Kinugawa Security Blog: MS12-023: IE9のself-XSS防止機能のバイパス
マイクロソフト セキュリティ情報 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)」のような、スクリプトを
Masato Kinugawa Security Blog: ドコモの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接続
Masato Kinugawa Security Blog: ブラウザのXSS保護機能をバイパスする(2)
第2弾です。第1弾はこちら。今回はアプローチがちょっと違います。 無視されるバイトの利用 タグ中に挿入されても無視されるバイトというのがあります。有名なのはIEの「0x00」のスルー(<scr[0x00]ipt>alert(1)</sc[0x00]ript>が動いてしまう)ですが、他にもブラウザと文字エンコーディングによっては無視されるバイトがあります。今回はこれをXSS保護機能のバイパスに使用します。 2か月ほど前に、個人的に無視されるバイトを各ブラウザ・各文字エンコーディングごとに網羅的に調査してみました。んで、この結果を掲載しようと思ったんですが、自分用にまとめたもので汚いし、まだいろいろ調査中の部分もあるのでそれはもうちょっとあとにします。結構たくさんあります。 IEのXSSフィルターをバイパスする IEのXSSフィルターはさすがにIEが「0x00」を無視することを知っています。
Masato Kinugawa Security Blog: Googleのmetaリダイレクトに存在した問題
Googleに存在したメールアドレスを窃取できた問題について書きます。これは2011年1月30日に報告し、報告後数日以内に修正された問題です。 こんなページがありました。 http://example.google.com/redirect?continue=http://example.google.com/xyz <meta http-equiv="refresh" content="0;url='http://example.google.com/xyz'"> <script> location.replace("http://example.google.com/xyz") </script> continueというパラメータに指定されたURLをmetaタグとlocation.replace()にそれぞれ入れて、JavaScriptの有効/無効の設定に関わらずリダイ
Masato Kinugawa Security Blog: CVE-2011-3879: chrome:// URLへのリダイレクト
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
Masato Kinugawa Security Blog: ブラウザのXSS保護機能をバイパスする
ChromeやSafariにはXSS Auditor、IE 8以上にはXSSフィルターという、XSSを検知してブロックする機能がそれぞれあります。 今回は、これを回避してみた記録です。 ・Chromeでバイパス はい！ついおととい報告したやつです！ XSS Auditor bypass with U+2028/2029 https://bugs.webkit.org/show_bug.cgi?id=78732 なぜかSafariではブロックされる(中の人も理由がわからないと言っていた)んだけど、Chromeでは動きます。以下で試してみてください。 http://vulnerabledoma.in/char_test?charset=utf-8&xss=1&body=%3Cscript%3E//%E2%80%A8alert(1)%3C/script%3E http://vulnerabled
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Masato Kinugawa Security Blog: 8月 2012