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

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 攻撃を可能にするので、いずれのケースであっても、指定すべきでな

    • そもそも攻撃者は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 を読んでみま

        • 攻撃の手順はブログ記事の方に書かれています。'unsafe-inline'をセットするのは攻撃者だと思いますよ。
          • by Anonymous Coward on 2017年09月11日 4時40分 (#3277046)

            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による制限を回避して情報を流出させることが出来る)ってなってますし、回避対象が制御下に有るわけが無いのは明白かと。

            この文脈の前提として「攻撃者はXSSが成功した際でもCSPによりそのデータを外部に取り出せない」というのがあるので、

            攻撃者にとってはXSSでデータを外部に送信するにあたりCSPが障壁となるが、
            XSS標的ページにて'unsafe-inline'が有効な状態にて、
            データ送信コードをwindow.openで生成したブランクページに、
            document.writeで書き込んで実行することで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サイトへデータを含んだリクエストを送ることができる。 』
                とでもしときましょうよ。

物事のやり方は一つではない -- Perlな人

処理中...