パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

AppleとGoogleが修正し、Microsoftが修正しなかった脆弱性とは」記事へのコメント

  • CSP を導入しているけど、インラインスクリプトが使えないと不便だからか 'unsafe-inline' を許可しているサイトも多いですが、危険だし、中途半端で美しくないポリシーだと思います。

    6. Content Security Policy Directives [w3.org] より

    In either case, developers SHOULD NOT include either 'unsafe-inline', or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.

    'unsafe-inline' は XSS 攻撃を可能にするので、いずれのケースであっても、指定すべきでな

    • by headless (41064) on 2017年09月10日 23時50分 (#3276989)
      そもそも攻撃者はW3C勧告に従わないでしょう。今回の話は攻撃者が自分のサイトで'unsafe-inline'を指定するというものですよ。
      親コメント
      • そもそも攻撃者はW3C勧告に従わないでしょう。今回の話は攻撃者が自分のサイトで'unsafe-inline'を指定するというものですよ。

        headless さんは、加害者のサイト http://bad.example.com/ [example.com] のWebサーバ に「Content-Security-Policy: 'unsafe-inline';」を指定して、http://bad.example.com/ 上の JavaScript コードで about:blank を開き、about:blank に注入した JavaScript コードから 被害者のサイト http://good.example.com/ [example.com] にアクセスする方法で脆弱性を利用するのだと、誤解しているように思えます。

        TALOS-2017-0306 - Cisco Talos [talosintelligence.com] の Details を読んでみましたが、実際に XSS 脆弱性を悪用して情報を盗み取る方法までは書かれておらず、シンプルに CSP 制限を迂回できることを脆弱性として指摘しているだけでした。

        しかし、実際にこの脆弱性を悪用する方法としては、被害者のサイトに「Content-Security-Policy: 'unsafe-inline';」が指定されている必要があります。

        参考までに TALOS-2017-0306 - Cisco Talos [talosintelligence.com] の Details を和訳してみました。

        • 攻撃者は、Content-Security-Policy ヘッダーをバイパスすることができる。このヘッダーは、Webサイトからの情報漏洩を防ぐための、ブラウザによる保護機能として作用する。
        • window.open("","_blank") を使用して新しいドキュメント(about:blank)を開き、その中に document.write でデータを書き込むことで、ドキュメントに設定された CSP 制限をバイパスすることができ、オリジナルページの JavaScript コード で他のウェブサイトにアクセスすることが可能になる。
        • 本来、CSP ヘッダーで unsafe-inline を指定したとしても、CSP 制限によりクロスサイトのアクセス(例えば、外部の 1x1px の画像の読み込み)はブロックされるはず。
        • この about:blank ページは、正しくはロード元のドキュメントと同じオリジンを持つはずですが、CSP による制限を受けていない(※訳注:これが脆弱性だという指摘)。これは、本来の仕様 https://w3c.github.io/webappsec-csp/#initialize-document-csp [github.io] とは異なる。
        • 試験結果によると、たとえば Firefox ではこの脆弱性はなく、新しいドキュメントも読み込み元のドキュメントから CSP を継承した。この脆弱性は、Apple Safari (CVE-2017-2419) と Google Chrome (CVE-2017-5033) にもあったが、修正された。

        Details なのに説明がシンプルすぎて逆に分かりにくいので、再現手順を例示すると、

        • http://example.com/ の HTTPレスポンスヘッダーに「Content-Security-Policy: 'unsafe-inline';」を返すようにWebサーバを設定する。
        • http://example.com/ の HTMLソースに JavaScript コードを埋め込み、
          • 「window.open("","_blank")」というコードで、新しいウインドウ about: blank を開き、
          • 新しいウインドウ about:blank に対して document.write で <img src="http://example.jp/" /> というHTMLコードを埋め込む (example.com じゃなくて別ドメインの example.jp)

        と、これだけ。

        本来、CSP 制限により http://example.com/ [example.com] から http://example.jp/ [example.jp] の画像にアクセスできないはずだけど、http://example.com/ から開いた about:blank からは http://example.jp/ [example.jp] にアクセスできてしまったという脆弱性です。

        これを実際に悪用する場合、アクセスするユーザーが脆弱性のあるブラウザ(Microsoft Edge)を使っているだけでなく、

        • 被害者のWebサイト http://good.example.com/ [example.com] の HTTPレスポンスヘッダーに「Content-Security-Policy: 'unsafe-inline';」が設定されている。
        • 被害者のWebサイトに XSS の脆弱性があり、インライン JavaScript を攻撃者が埋め込むことができる。

        の2つの条件を満たしている必要があります。

        CSP が正常に機能していれば、XSS脆弱性を悪用されて悪意のあるコードが埋め込まれたとしても、その悪意のあるコードからクロスドメインアクセスはできないはずだけど、Edge の脆弱性を使ったらそれができてしまうという内容です。

        親コメント
        • 攻撃の手順はブログ記事の方に書かれています。'unsafe-inline'をセットするのは攻撃者だと思いますよ。
          親コメント
          • Blog [talosintelligence.com] も読みました。

            "There are three main components to an exploitation attempt:" の段落については、あくまでも脆弱性を再現する手段の記述であって、実際に悪用するための方法ではないので、'unsafe-inline' をセットするのが攻撃者なのか被害者なのかは特に記述されていませんし、脆弱性の再現は 'unsafe-inline' をセットするのが誰であっても可能です。

            しかし、攻撃者が自分で管理している bad.example.com のHTTPヘッダーに "unsafe-inline" をセットして、そこから window.open() で about:blank を開いたとして、回避できるのはあくまでも bad.example.com に対する CSP の制限だけです。

            実際に何らかの悪用をするためには、"unsafe-inline" がセットされている good.example.com に XSS脆弱性でスクリプトをインライン埋め込みし、good.example.com に対する CSP の制限を回避する必要があります。

            ブログの文章にも "in order to bypass CSP restrictions put on the document." とはっきり書かれてます。the documentthe は、定冠詞であって、この場合 document を今話題にしている document に限定することを意味するのであって、任意のオリジン(任意のドメイン名)の document に対する制限をバイパスできるわけではありません。CSP の制約を回避できるのは、元の document (window.open のコードを埋め込んだ CSP が設定されたオリジンのdocument) に対してのみです。

            CSP による制限と、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) との違いについては、#3277045 [srad.jp] に書きました。

            親コメント
            • 「攻撃者が自分のサイト」ではなく「攻撃者が制御可能なサイト」と書くべきでしたが、ブログで説明されている攻撃手順の主語は攻撃者でしょう。ただし、もとから'unsafe-inlineがセットされたサイトを悪用する可能性については否定しません。同一生成元ポリシーの話はCSP未設定の場合の話です。
              親コメント
              • by Anonymous Coward

                言葉遊びやる前に、事実を無視して一方的にMSを悪者に仕立て上げる内容になってるストーリーの内容を修正したほうがいいと思うけどねぇ
                運営(しかもストーリー採用者)なんだから個人よりもまずスラド全体のことを考えてください

                それとも事実無根の話でMS叩くことがスラドにおける至上命題なのですか?

              • by Anonymous Coward

                エクスプロイトの手順としては攻撃対象も攻撃者が用意するってだけのような

                CSPは未設定の状態が一番緩くてこの脆弱性自体が「CSPの制約を回避する」って物なのだから
                実際の攻撃シナリオとしては標的になったサイトのunsafe-inlineを回避して未設定にする以外ありえないです

                あと同一生成元ポリシーはCSPの設定有無に関わらず適用される話でCSPに何を設定しても緩くはなりません
                (CSPは外部リソースを取り込む側、同一生成元ポリシーは取り込まれる側で制限したり許可したりする物です)

          • by Anonymous Coward

            CSPをセットすると基本的に未設定のときよりも制約が厳しくなるだけなので、
            攻撃者が自分のサイトにCSPをセットする意味がないように思います。
            何もなければsame-origin policyだけなのでリクエスト送信も、
            レスポンスのプラウザ主体での利用も制限されないはずです。

            ブログ記事の攻撃手順ってこのストーリーの2段落目に対応するざっくりした説明のことですよね?
            「An attacker may be able to bypass the policy specified by the Content-Security-Policy header, causing an information leak. 」
            (攻撃者はCSPによる制限を回避して情報を流出させることが出来る)ってなってますし、回避対象が制御下に有るわけが

            • ブログ記事の攻撃手順は「There are three main components to an exploitation attempt: setting the Content-Security-Policy for the browser with "unsafe-inline" directive to allow for inline script code, then~」の部分です。元から'unsafe-inline'がセットされたWebサイトを探してくるのではなく、攻撃者が何らかの方法で'unsafe-inline'をセットすると読むのが自然だと思います。
              親コメント
              • 「There are three main components to an exploitation attempt: ~略~」の段落については、あくまでも脆弱性の検証をするための実証方法・実証コードを示しているに過ぎません。

                「攻撃者が何らかの方法で'unsafe-inline'をセットすると読む」のではなく「脆弱性の再現検証を行う際には、検証者が 'unsafe-inline'をセットする(あるいは 'unsafe-inline' がセットされている環境を使用する)」と読むべきです。

                こう書くと、「exploitation attempt」の日本語訳は「悪用しようとする試み」なのだから「攻撃手段」だと反論されそうですが、「exploitation」は「exploit」の名詞系です。「exploit」という言葉は、情報セキュリティ分野での専門用語でして、エクスプロイトのWikipedia [wikipedia.org] を見れば分かるように「セキュリティ確認目的での、脆弱性検証するための実証コード(Proof of concept:PoC)を指すこともある。」(Wikipediaより引用)とされています。ブログに書いてあるのは「攻撃手順」というより「脆弱性の再現検証のための手順」です。

                当該脆弱性を実際に悪用するクラッカーが「何らかの方法で'unsafe-inline'をセットする」のは、合理的ではありません。攻撃者が「何らかの方法」例えばWebサーバの脆弱性を利用してHTTPヘッダーを操作できるのであるならば、何もそんなことをしなくても「Content-Security-Policy」を削除すれば CSP は完全に回避できるわけで、この脆弱性を利用する必要性は全くありません。

                親コメント
              • by Anonymous Coward

                #3276994 に書かれてることも理解できないのにMSを悪者にしようと必死にならなくてもいいよ
                運営なんだからしっかりしようよ、間違いは認めなよ

                それもできないでMS叩きしようと固執するのが今のスラドなの?

              • by Anonymous Coward

                最終的にCSPを回避できるという脆弱性なのですでにCSPか解除(未設定)されてるところにCSPを設定して攻撃する前提は成立しないし、
                そもそも「何らかの方法」でCSP設定を好きに変更できる脆弱性があるならいっそ解除してしまえば良いわけでやはり脆弱性として成立しない。

                脆弱性を結果から順に辿れば間違えようがないだろこんなの・・・
                ・CSPの迂回が可能という脆弱性
                ・CSPの迂回が発生するのはブランクウィンドウ内のコード
                ・ブランクウィンドウ生成とその中のコードをスクリプトで生成する
                ・生成するスクリプトはインラインで実行される
                ・unsafe-inlineがセットされた状況である
                ・脆弱性の前提としてXSSが関係している
                サイト一つとブランクウィンドウしか出てこなくて、CSPの迂回が目的でCSPがセットされているのはそのサイト。

                つーかさ、普段は誤字脱字をさらっと修正しててhylomより遥かに優秀な感じなのになんでこのストーリーだけこんな馬鹿晒してんの?

              • そういう解釈もできますが、元記事の説明はあいまいですね。The Registerも攻撃者の行為と解釈しているようです。セキュリティ用語の「exploit」は動詞ではなく名詞扱いではありませんか。
                親コメント
              • by Anonymous Coward

                つまりheadlessさんは一次情報のTalos detailsよりも
                単なるまとめサイトみたいなメディアThe Registerを信用して
                まんまと誤解したということね。
                CSPとかセキュリティの基礎知識がないと、仕方ないね。

                exploitは(というか英語はなんでもそうだけど)動詞にも名詞にも使いますね。
                だいたいは冠詞でわかるのでは?
                I lookとTake a lookみたいに。
                ていうか反論するとこ、そこなの?

                もうスラドはheadlessさん一人でもっている状態なんだから、
                見苦しい言い訳はやめて、今後のいい記事につなげてくださいよ。

              • by Anonymous Coward

                新iPhoneの直前でMSやGoogleをなんとしても叩くようApple陣営の方から依頼されてるんだろうね

              • 「exploit」という単語が名詞か動詞かという話をしているのではなく、「exploitation」の話をしているんですよ。exploitationのもとになるexploitは動詞です。exploitは名詞扱いならPoCなどの意味で使われますが、動詞扱いならPoCではなく脆弱性を利用して攻撃すると解釈する方が自然です。ただし、元記事の表現があいまいなので、ストーリーでは主語を落とした表現にしたわけです。
                親コメント
              • by Anonymous Coward

                落とした表現でっていうなら
                『「'unsafe-inline'」を有効にし、』
                →『「'unsafe-inline'」を有効な状態で、』
                とするほうが良いのでは。

                あと、
                『新しいドキュメントは元のドキュメントと同一生成元だが、CSPが無効化されるため』
                →『新しいドキュメントはCSPが無効化されるため』
                『同一生成元ポリシーを無視して他のWebサイトからデータを読み取ることができる。 』
                →『CSPを無視して他のWebサイトへデータを含んだリクエストを送ることができる。 』
                とでもしときましょうよ。

      • by Anonymous Coward on 2017年09月11日 0時41分 (#3277011)

        攻撃者が自分のサイトに設置するんなら最初からCSP自体設定しなければいいのでは。

        今回の話は'unsafe-inline'な設定の標的サイトに対して、攻撃者がXSSな投稿を行い、
        それをEdgeで踏んだ場合に、親コメントに有るような小細工無しで
        「window.open()
        →document.write()
        →CSP未設定なabout:blank経由で任意のサイトへアクセス
        →CSRFまたはXSSにより取られたデータの外部送信」
        が発生するって脆弱性だと思うのですが。

        親コメント
        • CSPが未設定だと同一生成元ポリシーに弾かれるのではありませんか。
          親コメント
          • headless さんの解釈だと、攻撃者が、攻撃者の管理するサイトの CSP に 'unsafe-inline' を指定し、そこから about:blank を開くことで、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) を回避して、異なるオリジンのリソースとやり取りし放題になる脆弱性だということでしょうか?

            もし、そうだとしたら、例えば任意のドメイン名のWebサイトからCookieを盗めることになり、世界中が大騒ぎになってますよ。

            • ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) による制限
            • Content Security Policy (CSP) による追加の制限

            の2つを勘違いされているようです。今回の問題はあくまでも後者です。

            その根拠は、TALOS-2017-0306 - Cisco Talos [talosintelligence.com] の下記の記述

            One could argue that the code was loaded with unsafe-inline in the CSP header, but that should still block any cross-site communication (e.g. 1x1px tracking image etc).

            異なるオリジンへのネットワークアクセスの仕様 [mozilla.org] を理解していれば分かりますが、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) では、別のオリジンからの画像の読み込みはブロックされません。それがブロックされると書かれているので、あくまでも Content Security Policy (CSP) による制限の話です。

            親コメント
          • by Anonymous Coward

            同一生成元ポリシーで別オリジンと判定されてもリクエストを飛ばす類の事は大体問題なく許可されます。
            CORSで利用を許可する方法からしてレスポンスからヘッダを確認とかなので、リクエストは飛んでしまいます。
            CORSで許可されないと無理なのは取得した内容の利用や操作だけでブラウザ上の表示とかは普通に行われます。

            なのでXSSした標的のサイトから取ったデータを攻撃者が管理するサーバに送るのに制限はありませんし、
            Access-Control-Allow-Originをつければ次の操作指示を流し込むことも出来ます。
            CSRFを行う場合はCSRF先の防御状態に依存するのでなんともいえませんけ

            • by Anonymous Coward

              #3277042 の内容は、もう 'unsafe-inline' を使うかどうかと関係ない話になってるので
              その領域まで行ってしまった推測はほぼ確実に間違った解釈だろうと言える

              また、このコメの流れを見ればわかる通り、 headless 自体が今回の脆弱性の内容を正しく理解できていない
              誤った脆弱性情報を流すことはまさにそれ自体が社会の迷惑以外の何物でもないので
              可能であればいったんストーリー自体を取り下げるか、大幅修正するべきだろう

              そもそもなぜそんな曖昧な認識のまま、
              あたかもMSが悪かのようなタイトルで記事を掲載してしまったのか
              スラドそのものの体制から見直すべきいい機会だと思う

              • by Anonymous Coward

                #3277042は#3277037のコメントに対する返信なのでCSP未設定の場合の話であってますよ。
                headless氏の誤解を前提とすると矛盾が生じるって話なので。

                > あたかもMSが悪かのようなタイトルで記事を掲載してしまったのか
                確かにheadless氏は攻撃手順を誤解してはいるようですが、
                'unsafe-inline'なCSP制限下で制限を回避できてしまうのは事実ですし、
                #3276913の内容を見ると分かるようにCSP3(のnon-normativeな項目)ではCSPは継承するべきとされるようです。
                CSP2では該当箇所が見当たらないのでCSP2ではリーガルな挙動であり、
                MSはCSP3のnon-normativeな項目にはまだ対応して

              • by Anonymous Coward

                今回の件でいえば、 headless 氏が

                「すべての外部サイトに対して攻撃者が好きに攻撃し放題の重大脆弱性なんだ、それをMSだけ修正しないんだ」

                と一人で勘違いした結果、
                ストーリーのタイトルや文面がMSに対して強い攻撃性を持った内容になっていることが重大な問題

                もっと言えばタイミングも最悪で、9/12の某林檎イベントの直前となっている
                イベントの前に何が何でもMSを叩きたいという思考が暴走した結果の勘違い(または意図的なフェイクニュース)と思われても仕方がない

      • by Anonymous Coward

        Edgeで初期状態で有効なポップアップブロックをわざわざ無効にして攻撃者のサイトにアクセスし、
        さらにほとんどのブラウザやアンチマルウェアソフトウェアで搭載されるようになったサイトチェックも無効にしていて、
        さらに攻撃者の狙った通りに攻撃コードが機能するサイトを他に開いていて、
        挙句に(サイトチェックではなく、ローカル監視としての)アンチマルウェアソフトウェアが攻撃コードを検知せずに実行を許可したとき、
        もしかしたら成立するかもしれないね

        そうだね、もうHTTPなんて使うなよ

最初のバージョンは常に打ち捨てられる。

処理中...