タグ

ブックマーク / masatokinugawa.l0.cm (23)

  • Masato Kinugawa Security Blog: ユーザ入力を使った正規表現から生じるDOM based XSS

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

    ockeghem
    ockeghem 2018/02/06
    外部入力値から正規表現を構成してはいけない、と
  • Masato Kinugawa Security Blog: hiddenなinput要素でユーザー操作を使わずにXSS

    徳丸さんがブログで紹介されたことで、<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'); ?

    ockeghem
    ockeghem 2016/04/14
    これはすごい>『style属性にbehaviorをつけ、behaviorのURLの値に、任意の同一オリジン内のURLを指定すると、たとえhiddenの中でも、onreadystatechangeイベントが発火』
  • Masato Kinugawa Security Blog: Referrer文字列によるXSS part2

    以前、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でどうぞ

    ockeghem
    ockeghem 2014/06/30
  • Masato Kinugawa Security Blog: CVE-2014-0509: 上位サロゲートを使ったFlashのXSS

    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パ

    ockeghem
    ockeghem 2014/06/02
    『つくづく、何も考えずにひとまず適当に試してみるのもバグの発見には重要な行為だと感じます』
  • Masato Kinugawa Security Blog: OWASP AppSec APAC 2014で発表しました

    OWASP AppSec APAC 2014 で、はせがわようすけさん、malaさんと一緒に、「XSS Allstars from Japan」という枠で登壇しました。3人それぞれ好きなテーマについて発表をしたのですが、僕は、2011年頃から個人的にやってきた、文字エンコーディングの調査について発表しました。 スライドは以下で公開されています。 The Complete Investigation of Encoding and Security // Speaker Deck はせがわさんのスライドはこちら: Bypass SOP, Theft your data // Speaker Deck malaさんのスライドはこちら: XSS with HTML parsing confusion // Speaker Deck エンコーディングに関する様々な調査結果は以下で公開しています。

    ockeghem
    ockeghem 2014/03/26
  • Masato Kinugawa Security Blog: CVE-2014-0491: AS2の関数に存在したjar:を通じたXSS

    これは、2013年11月8日に報告し、 2014年1月のアップデートで修正された、AS2の普通JavaScriptが実行できるべきでない複数の関数で、JavaScriptを実行できた問題です。 https://helpx.adobe.com/security/products/flash-player/apsb14-02.html These updates resolve a vulnerability that could be used to bypass Flash Player security protections (CVE-2014-0491). FlashのnavigateToURLに指定するURLで、jar:というプロトコルをURLの先頭につけると、セキュリティ制限を突破できてしまうことが、 Soroush Dalili氏によって公開されていました。( https://

    ockeghem
    ockeghem 2014/03/02
    『Flashはバグが多いです…サービス運営者は、危険になる可能性を少しでも減らすために、必要ないFlashファイルを1度整理されるといいと思います』
  • Masato Kinugawa Security Blog: GoogleからNexus 5をもらった

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

    ockeghem
    ockeghem 2014/01/30
    『Googleのセキュリティチームの人たちは、変わった問題を報告しても、そんなマニアックなの知るか、みたいなことはなく、バグの面白さも含めて理解してくれるので、面白さを共有できることも僕の楽しみの一つです』
  • Masato Kinugawa Security Blog: CVE-2013-5612: Firefoxのcharsetの継承によるXSS

    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という情報セキュリテ

    ockeghem
    ockeghem 2013/12/12
  • Masato Kinugawa Security Blog: MS13-037: エンコーディングの自動選択の強制によるXSS

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

    ockeghem
    ockeghem 2013/12/01
  • Masato Kinugawa Security Blog: Referrer文字列によるXSS

    リファラを使った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

    ockeghem
    ockeghem 2013/10/29
    おお>『IE×リファラ でXSSが可能なことは、知ってる人は知っているのではないかと思いますが、 今回は、ChromeやSafariでも攻撃が可能だということを紹介します』
  • Masato Kinugawa Security Blog: accounts.google.comに存在したXSS

    Googleの脆弱性報酬制度の報酬がアップされましたね! Google、脆弱性情報に支払う報奨金を大幅アップ - ITmedia エンタープライズ http://www.itmedia.co.jp/enterprise/articles/1306/10/news027.html Googleアカウントページに存在するクロスサイトスクリプティング(XSS)の脆弱性情報については3133.7ドルから7500ドル accounts.google.comのXSSは$7,500 だそうです。みつけたいですね! みつけるのはかなり厳しいと思いますが、かつて2つみつけたことがあります。 今日はそのうち1つを紹介したいと思います。 oeパラメータを使ったXSS 2012年12月27日に報告し修正された問題です。 Googleは、一部のサービスで「oe」というクエリパラメータを付加することで、ページの表示に

    ockeghem
    ockeghem 2013/06/19
    accounts.google.comのXSSが$7,500にアップされる前に、CoolなXSSを見つけて$5,000もらったお話。GJ!
  • Masato Kinugawa Security Blog: Flash動画プレイヤー「ふらだんす」に存在したXSSから学ぶ、FlashのXSS3パターン

    ストリーミング・ジャパンが以下のURLで提供しているFlash動画プレイヤーの「ふらだんす」に存在し修正された、僕が報告した3件のXSSについて書きます。 http://www.streaming.jp/fladance/ 更新しましょう 2013年4月12日に提供されたバージョン 2.1.5以降 を使っていなければXSSの穴をサイトに作っていることになります。一応「ふらだんす」の上で右クリックすると使っているバージョンがわかるので脆弱かどうか確認できますが、こういったFlashの動画プレイヤーの更新情報をちゃんとチェックしている人はほとんどいないと思うので、最近導入した人でなければまず脆弱なものを使っていると思います。心当たりがある人は「2.1.5」に更新しましょう。あるいは使っているサイトをみかけたら教えてあげましょう。 これ以降は技術的な話です。 技術的な話 あらかじめことわっておく

    ockeghem
    ockeghem 2013/04/26
    『このExternalInterface.call()の実装はあまりにひどいですが、この問題の報告者によるとAdobeは「後方互換性のために変更しない」と返事した』
  • 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ベクタに関して特に面白いことはないので

    ockeghem
    ockeghem 2013/02/10
    document.domain="twitter.com";の設定による影響の考察。document.domainの影響の話題はたまに聞くがドキュメントがあまりなく興味深い
  • Masato Kinugawa Security Blog: GoogleからNexus 10をもらった

    日頃の行いがいいので、もらいました!! ホリデーギフトという名目で、去年はChromebookを貰った(※受け取ったのは2012年なんだけど、話をもらったのは2011年)んですが、今年はNexus 10を頂きました。 タブレット、僕は1個も持ってなくて、ちょうどほしいと思ってたところだったので、嬉しいです! 今年はどちらかというとブラウザの脆弱性を探す方に力を入れていたので、前年よりはGoogleサービスの脆弱性報告はしていなかったのですが、気が向いた時に探したり、ブラウザの問題絡みでGoogleのサービスに影響を与える問題などを報告したりして、まぁそこそこは報告していました。 最近はこんな、上位報告者のリストみたいなのも掲載されてるみたいで、 The "0x0A List" – Application SecurityGoogle http://www.google.com/abo

    ockeghem
    ockeghem 2012/12/26
    おめでとうございます。すごいなぁ
  • 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 :

    ockeghem
    ockeghem 2012/11/27
    黒魔術のようなXSSの解説だが、Kinugawaさんが白の方で本当に良かった
  • Masato Kinugawa Security Blog: OperaのEUC-TWに存在した潜在的にXSSが可能な問題

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

    ockeghem
    ockeghem 2012/11/07
    是非達成を!>『Operaの脆弱性のCVE番号をゲットすれば、「5大ブラウザのCVE番号をゲットする」のアチーブメントをアンロックできるんですけど、なかなか難しいですね。また挑戦します』
  • 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無利息キャッシング – キャッシ

    ockeghem
    ockeghem 2012/09/06
    『jQuery Mobile 1.2 Betaがさきほどリリース…それに満たないバージョンのjQuery Mobileには読み込んでいるだけでXSS脆弱性を作ってしまう』
  • 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

    ockeghem
    ockeghem 2012/08/02
    よく見つけるなぁ…ブラウザなどの未修正の問題だが修正されるあてがなく、アプリ側で対処可能な場合は、公開して注意喚起した方がよい場合がある、ということですね
  • Masato Kinugawa Security Blog: 「めんどうくさいWebセキュリティ」を頂いた

    「めんどうくさいWebセキュリティ」、原著の「The Tangled Web」に僕の名前が掲載されているのをきっかけに、監修された上野さん(@sen_u)を通して、出版元である翔泳社様から献して頂きました。ありがとうございます。 こういう人にオススメです。 ・Webを隅々まで理解したい ・セキュリティに絡んだ、細かなブラウザの動きに興味がある ・自分の持っているブラウザ周辺のWebセキュリティ知識を確認したい 逆にこれからWebセキュリティを学びたい・手っ取り早くWebセキュリティの知識をつけたいという人にはお勧めできません。踏み込んだ話ばかりなので、最初に手に取るには細かすぎると思います。(徳丸をどうぞ!) このでは、URL/HTTP/HTMLなどのWebの構成要素を詳細に見ていくことで、ブラウザのセキュリティがどのように成り立っているかや、そこにどのようなセキュリティ問題が存在す

    ockeghem
    ockeghem 2012/07/18
    さすがはKinugawaさんという、とても面白い書評>『つぎはぎだらけで今にも壊れてしまいそうなWebの現状を根本から伝えてくれています』
  • Masato Kinugawa Security Blog: NoScriptのAnti-XSS機能のバイパス18個

    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

    ockeghem
    ockeghem 2012/07/08
    『NoScriptが特に優れている点は、問題が発見された時の対応の早さだと思います。NoScriptの開発者であるGiorgio氏は、どれもその日のうちにrc版をリリースしてくれる』