お久しぶりです＆あけましておめでとうございます。昨年はブログを書く時間をうまく作ることができず、あまり記事を書けませんでした。今年はできるだけ月に1回程度何か書いていきたいと思っています。今年もよろしくお願いします！ さて、ブログを書かなかった間にXSSからSQLインジェクションへ興味が移った、なんてことはありませんでしたので、今日もいつも通り大好きなXSSの話をしたいと思います！ 最近、正規表現にユーザ入力を使っていることに起因するDOM based XSSに連続して遭遇しました。あまり見慣れていない注意が必要な問題だと思うので、この記事では、見つけたもの2つがどのように生じたか、また、問題を起こさないためにどうすればよいかを紹介します。 そのうちの1つはLINEのBug Bounty Programを通じて報告した問題です。 賞金と、"LINE SECURITY BUG BOUNTY"

徳丸さんがブログで紹介されたことで、<input type=hidden>でのXSSが話題になっていますね！ hiddenなinput要素のXSSでJavaScript実行 | 徳丸浩の日記 http://blog.tokumaru.org/2016/04/hiddeninputxssjavascript.html 僕もちょうど、個人での検証の過程で発見した、hiddenでのXSS手法について、そろそろ共有しようと思っていたところでした。皆の関心が高いうちに、もう1つの方法を共有したいと思います！ 徳丸さんのコードに倣って紹介します。今回は問題を簡単にするためにX-XSS-Protection:0をつけさせてもらいます。 <?php header('X-XSS-Protection:0'); header('Content-Type:text/html;charset=utf-8'); ?

2015年6月頃にみつけた、toolbar.google.com の、少し変わったXSSを2つ紹介します。 The English version is here: http://mksben.l0.cm/2016/01/google-toolbar-xss.html 何が変わっているか このXSSは、Google ToolbarがインストールされているIEでしか動作しません。Google Toolbarがインストールされていると、toolbar.google.com 上に用意されたUIから、ツールバーを操作するコマンドを実行できるようになります。このコマンドを利用することでXSSに繋げるという点が、よくあるものとは異なります。 どのようにコマンドを実行しているか toolbar.google.com 上の次のページをみると、こんなコードを発見できます。 http://toolbar.go

English version: http://mksben.l0.cm/2015/12/xxn.html ------------------------------------------------ 2015年12月のMicrosoftの月例アップデートで修正された、Internet ExplorerとEdgeのXSSフィルターに存在した問題(CVE-2015-6144 および CVE-2015-6176)について書きます。 2015 年 12 月のマイクロソフト セキュリティ情報の概要 https://technet.microsoft.com/ja-jp/library/security/ms15-dec.aspx 修正された問題は、2015年10月に行われたセキュリティカンファレンスのCODE BLUEで詳細を伏せて発表した、IE/EdgeのXSSフィルターの動作を利用してXS

English version: http://mksben.l0.cm/2015/07/codeblue.html -------------------------------------------------------- 2014年12月に開催された国際セキュリティ会議、CODE BLUEで、「バグハンターの愉しみ」というタイトルで発表させて頂きました。先日、公式ページでスライドが公開されましたので、僕のスライドをここでも共有します。 他のスピーカーの方々のすごいプレゼンは以下で見られます。 http://codeblue.jp/2015/archive/2014/ 講演の動画はポリシーにより公開していません。 会場の雰囲気はITmediaと@ITに書いて頂いた記事からお楽しみください。 Googleへの報告件数は世界2位：脆弱性発見のプロ「キヌガワ マサト」さんは日本人だった

Hi! Are you English-speaker? Good news! Finally, I started my blog in English: http://mksben.l0.cm/2015/06/bypassing-xss-filter-showmodaldialog.html Ｉ'm not good at English, but I think it is easier to read than Google translate. Maybe. Enjoy! ----------------------------------------------------------------------------- 先日、古くからあるJavaScriptの関数の1つの、showModalDialogの挙動について詳しくみていました。showModalDialogは、Ch

Flashを使った、ちょっと変わった情報奪取手法を紹介します。 この手法、以前から条件によっては攻撃が可能になる場合があるだろうと想像していたんですが、なかなか実例にぶつからず、2013年に開催されたサイボウズの脆弱性発見コンテスト「cybozu.com Security Challenge」で初めて本当に動作するものを発見しました。 実は既に「SECCON 2013 全国大会」でも一部詳細を発表しています。スライドの15ページの辺りから書いてある件です。 http://www.slideshare.net/masatokinugawa/cybozu-security-challenge/15 発表の時点ではサイボウズ側で修正されていなかったので、具体的な箇所を伏せていますが、今は修正されたので、具体的な箇所をあげながら説明したいと思います。 なお、この問題はFlash自体の脆弱性ではない

12月と言えばXSS-Masの季節ということで、最近は、XSS-Mas前から1月の終わりまで開催されていた、賞金付きXSSチャレンジ「Cure53 XSS-Mas Challenge 2014」に挑戦していました。 XSSチャレンジというのは、出題者がわざとわかりにくい形でXSSに脆弱にしたページ(例：特定の記号や文字が使えない、文字数制限がある等)で、指定した条件(alert関数 で「1」の文字をだすとか)をクリアして、スクリプトが実行できることを証明するという、XSSを嗜む人たちの間で楽しまれる一種のパズルゲームです。 実際にXSSで攻撃可能なことを証明しないといけない場面でも、特定の制約がかかることは多く、こういったチャレンジは単なるパズル遊びというだけでなく、攻撃の発想を養ううえでとても有益なものです。

この記事は 脆弱性"&'<<>\ Advent Calendar 2014　10日目の記事です！ 発見したFlashのlocal-with-filesystem Sandboxをバイパスできた複数の脆弱性(CVE-2014-0534, CVE-2014-0537 か CVE-2014-0539, CVE-2014-0554)について書きます。 CVE-2014-0534 http://helpx.adobe.com/security/products/flash-player/apsb14-16.html http://helpx.adobe.com/security/products/flash-player/apsb14-17.html CVE-2014-0554 http://helpx.adobe.com/security/products/flash-player/apsb14-

Internet Explorerで細工したページに対し印刷プレビューを実行すると、ページ内の情報が外部に漏えいする場合があった脆弱性について書きます。本問題は、Microsoft提供の更新プログラムにより現在は修正されています。 この問題は、Microsoftが2013年の6-7月に30日間限定で実施したIE11 Previewの脆弱性報酬制度を通じて報告したものです。その後、報酬対象として受理され、$1,100を頂きました。 報酬は次のようなデビットカードで支払われました。 IE11のBounty Program( http://t.co/Xx2WUOut43 )のデビットカードが届いた！ありがとうMicrosoft！ pic.twitter.com/It1LzVAAyC — Masato Kinugawa (@kinugawamasato) 2013, 9月 27 カード右上の金額が

先月に続いて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指定がある場合

また最近IEのXSSフィルターのバイパスに挑戦してみました。 いくつか面白い隙をみつけたので紹介します。 今回は文字列リテラルでのXSSに対する検知をバイパスします。 1. onerrorとthrowを使ってXSSする 以前Gareth Heyes氏が紹介していた、onerrorとthrowの手法を使うと、XSSフィルターをバイパスできることに気が付きました。 XSS technique without parentheses http://www.thespanner.co.uk/2012/05/01/xss-technique-without-parentheses/ Win7 IE9(ドキュメントモードがIE9)で有効です。IE10以降では改善され、"[JavaScriptの区切り]onerror= がフィルタ対象になっているようです。 http://vulnerabledoma.i

以前、Referrer文字列を使ったXSSはIEだけでなくChromeやSafariでもできるということを以下の記事で紹介しました。 http://masatokinugawa.l0.cm/2013/10/referrer-xss.html が、その後のブラウザのアップデートで、紹介したdata: URLからReferrerをつける手法は使えなくなってしまいました。現在は、data: URLに<meta name="referrer" content="always">指定があっても、Referrerを送信しないように変わったようです。 ということで今回は、今も使える別のReferrerによるXSS手法を紹介したいと思います。 Safari( 最新の7.0.4で確認 )のみ動作します。以前はChromeでも動いていたのですが、33あたりから使えなくなりました。 以下からSafariでどうぞ

Flashの文字列処理の方法が適切でないために、 適切にXSS対策が施されたFlashファイル上でもXSSを引き起こせる場合があった問題について書きます。 この問題は以下に掲載されているように、 2014年4月のFlash Playerのアップデートで修正されました。 http://helpx.adobe.com/security/products/flash-player/apsb14-09.html These updates resolve a cross-site-scripting vulnerability (CVE-2014-0509). 本問題は、 このブログでも何度か取り上げた ExternalInterface.call() の問題に関係するものです。取り上げたのはこの辺の記事です： Flash動画プレイヤー「ふらだんす」に存在したXSSから学ぶ、FlashのXSS3パ

Flash Playerに存在した、 セキュリティ制限をバイパスすることができた問題について書きます。この問題は2013年11月10日にAdobeに報告し、2014年3月のアップデートで修正されました。 http://helpx.adobe.com/security/products/flash-player/apsb14-08.html These updates resolve a vulnerability that could be used to bypass the same origin policy (CVE-2014-0503). 早速どのような問題だったか書いていきます。 (なお、本問題はFirefoxにインストールしたFlash Playerでしか再現しませんでした。) loader.load() という関数があります。この関数は、画像やSWFなどをSWF上にロードす

2013年もGoogleの脆弱性報酬制度を通じて脆弱性報告を続けていました。 2013年も上位の貢献者だったということで、今年もGoogleからプレゼントを頂きました！ Nexus 5です！やった！ 実は最近自分の使っていた携帯電話が壊れてしまって、ちょうど新しいのを買おうと思っていたところでした。去年はNexus 10、一昨年はChromebookを頂いていたので、今年出たGoogleの製品と言えばNexus 5かも、なんてひそかに思っていたらその通りだったので本当に嬉しいです。 フード付きの服ももらいました。表はSecurity Bot がプリントされています。 2013年は報酬の大幅アップが発表されたこともあり、結構力を入れてバグを探していました。 いまGoogleのバグを探すのは大変ですが、だからこそ、それを乗り越えたときに味わえる特別な楽しみがあります。 また、Googleのセキ

Firefox 26で修正された、 オリジンを超えて文字エンコーディングを継承させることができたため、 XSSを引き起こせる場合があったバグについて書きます。 MFSA 2013-106: Character encoding cross-origin XSS attack https://www.mozilla.org/security/announce/2013/mfsa2013-106.html 一言で言います。 エンコーディング指定がないページに対し、POSTリクエストを送ると、たとえオリジンが異なっても、 POSTリクエストを送ったページのエンコーディングを使ってページを表示することができていました。 つまり、エンコーディング指定がないページで自動選択されるエンコーディングを、外部のサイトが自由に選択できたということです。 発見のきっかけはZDResearchという情報セキュリテ

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つのケースを取り上げたいと思います。 ケ