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.
"There are three main components to an exploitation attempt:" の段落については、あくまでも脆弱性を再現する手段の記述であって、実際に悪用するための方法ではないので、'unsafe-inline' をセットするのが攻撃者なのか被害者なのかは特に記述されていませんし、脆弱性の再現は 'unsafe-inline' をセットするのが誰であっても可能です。
そもそも 'unsafe-inline' は危険なので使うべきではないとW3C勧告に書かれている (スコア:3)
CSP を導入しているけど、インラインスクリプトが使えないと不便だからか 'unsafe-inline' を許可しているサイトも多いですが、危険だし、中途半端で美しくないポリシーだと思います。
6. Content Security Policy Directives [w3.org] より
'unsafe-inline' は XSS 攻撃を可能にするので、いずれのケースであっても、指定すべきでな
そういう問題ではない (スコア:1)
被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:3, 参考になる)
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 を読んでみま
Re: (スコア:1)
Re: (スコア:2)
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.
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re: (スコア:0)
言葉遊びやる前に、事実を無視して一方的にMSを悪者に仕立て上げる内容になってるストーリーの内容を修正したほうがいいと思うけどねぇ
運営（しかもストーリー採用者）なんだから個人よりもまずスラド全体のことを考えてください
それとも事実無根の話でMS叩くことがスラドにおける至上命題なのですか？
Re: (スコア:0)
エクスプロイトの手順としては攻撃対象も攻撃者が用意するってだけのような
CSPは未設定の状態が一番緩くてこの脆弱性自体が「CSPの制約を回避する」って物なのだから
実際の攻撃シナリオとしては標的になったサイトのunsafe-inlineを回避して未設定にする以外ありえないです
あと同一生成元ポリシーはCSPの設定有無に関わらず適用される話でCSPに何を設定しても緩くはなりません
(CSPは外部リソースを取り込む側、同一生成元ポリシーは取り込まれる側で制限したり許可したりする物です)