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

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'をセットするのは攻撃者だと思いますよ。
          • 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は外部リソースを取り込む側、同一生成元ポリシーは取り込まれる側で制限したり許可したりする物です)

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

処理中...