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' をセットするのが誰であっても可能です。
ブログの文章にも "in order to bypass CSP restrictions put on the document." とはっきり書かれてます。the document の the は、定冠詞であって、この場合 document を今話題にしている document に限定することを意味するのであって、任意のオリジン（任意のドメイン名）の document に対する制限をバイパスできるわけではありません。CSP の制約を回避できるのは、元の document (window.open のコードを埋め込んだ CSP が設定されたオリジンのdocument) に対してのみです。
ブログ記事の攻撃手順ってこのストーリーの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'をセットすると読むのが自然だと思います。
そもそも '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 を読んでみましたが、実際に XSS 脆弱性を悪用して情報を盗み取る方法までは書かれておらず、シンプルに CSP 制限を迂回できることを脆弱性として指摘しているだけでした。
しかし、実際にこの脆弱性を悪用する方法としては、被害者のサイトに「Content-Security-Policy: 'unsafe-inline';」が指定されている必要があります。
参考までに TALOS-2017-0306 - Cisco Talos [talosintelligence.com] の Details を和訳してみました。
Details なのに説明がシンプルすぎて逆に分かりにくいので、再現手順を例示すると、
と、これだけ。
本来、CSP 制限により http://example.com/ [example.com] から http://example.jp/ [example.jp] の画像にアクセスできないはずだけど、http://example.com/ から開いた about:blank からは http://example.jp/ [example.jp] にアクセスできてしまったという脆弱性です。
これを実際に悪用する場合、アクセスするユーザーが脆弱性のあるブラウザ（Microsoft Edge）を使っているだけでなく、
の2つの条件を満たしている必要があります。
CSP が正常に機能していれば、XSS脆弱性を悪用されて悪意のあるコードが埋め込まれたとしても、その悪意のあるコードからクロスドメインアクセスはできないはずだけど、Edge の脆弱性を使ったらそれができてしまうという内容です。
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア: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.com に対する CSP の制限だけです。
実際に何らかの悪用をするためには、"unsafe-inline" がセットされている good.example.com に XSS脆弱性でスクリプトをインライン埋め込みし、good.example.com に対する CSP の制限を回避する必要があります。
ブログの文章にも "in order to bypass CSP restrictions put on the document." とはっきり書かれてます。the document の the は、定冠詞であって、この場合 document を今話題にしている document に限定することを意味するのであって、任意のオリジン（任意のドメイン名）の document に対する制限をバイパスできるわけではありません。CSP の制約を回避できるのは、元の document (window.open のコードを埋め込んだ CSP が設定されたオリジンのdocument) に対してのみです。
CSP による制限と、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) との違いについては、#3277045 [srad.jp] に書きました。
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re: (スコア:0)
言葉遊びやる前に、事実を無視して一方的にMSを悪者に仕立て上げる内容になってるストーリーの内容を修正したほうがいいと思うけどねぇ
運営（しかもストーリー採用者）なんだから個人よりもまずスラド全体のことを考えてください
それとも事実無根の話でMS叩くことがスラドにおける至上命題なのですか？
Re: (スコア:0)
エクスプロイトの手順としては攻撃対象も攻撃者が用意するってだけのような
CSPは未設定の状態が一番緩くてこの脆弱性自体が「CSPの制約を回避する」って物なのだから
実際の攻撃シナリオとしては標的になったサイトのunsafe-inlineを回避して未設定にする以外ありえないです
あと同一生成元ポリシーはCSPの設定有無に関わらず適用される話でCSPに何を設定しても緩くはなりません
(CSPは外部リソースを取り込む側、同一生成元ポリシーは取り込まれる側で制限したり許可したりする物です)
Re: (スコア:0)
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による制限を回避して情報を流出させることが出来る)ってなってますし、回避対象が制御下に有るわけが
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:2)
「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 は完全に回避できるわけで、この脆弱性を利用する必要性は全くありません。
Re: (スコア:0)
#3276994 に書かれてることも理解できないのにMSを悪者にしようと必死にならなくてもいいよ
運営なんだからしっかりしようよ、間違いは認めなよ
それもできないでMS叩きしようと固執するのが今のスラドなの？
Re: (スコア:0)
最終的にCSPを回避できるという脆弱性なのですでにCSPか解除(未設定)されてるところにCSPを設定して攻撃する前提は成立しないし、
そもそも「何らかの方法」でCSP設定を好きに変更できる脆弱性があるならいっそ解除してしまえば良いわけでやはり脆弱性として成立しない。
脆弱性を結果から順に辿れば間違えようがないだろこんなの・・・
・CSPの迂回が可能という脆弱性
・CSPの迂回が発生するのはブランクウィンドウ内のコード
・ブランクウィンドウ生成とその中のコードをスクリプトで生成する
・生成するスクリプトはインラインで実行される
・unsafe-inlineがセットされた状況である
・脆弱性の前提としてXSSが関係している
サイト一つとブランクウィンドウしか出てこなくて、CSPの迂回が目的でCSPがセットされているのはそのサイト。
つーかさ、普段は誤字脱字をさらっと修正しててhylomより遥かに優秀な感じなのになんでこのストーリーだけこんな馬鹿晒してんの？
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re: (スコア:0)
つまりheadlessさんは一次情報のTalos detailsよりも
単なるまとめサイトみたいなメディアThe Registerを信用して
まんまと誤解したということね。
CSPとかセキュリティの基礎知識がないと、仕方ないね。
exploitは（というか英語はなんでもそうだけど）動詞にも名詞にも使いますね。
だいたいは冠詞でわかるのでは?
I lookとTake a lookみたいに。
ていうか反論するとこ、そこなの？
もうスラドはheadlessさん一人でもっている状態なんだから、
見苦しい言い訳はやめて、今後のいい記事につなげてくださいよ。
Re: (スコア:0)
新iPhoneの直前でMSやGoogleをなんとしても叩くようApple陣営の方から依頼されてるんだろうね
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re: (スコア:0)
落とした表現でっていうなら
『「'unsafe-inline'」を有効にし、』
→『「'unsafe-inline'」を有効な状態で、』
とするほうが良いのでは。
あと、
『新しいドキュメントは元のドキュメントと同一生成元だが、CSPが無効化されるため』
→『新しいドキュメントはCSPが無効化されるため』
『同一生成元ポリシーを無視して他のWebサイトからデータを読み取ることができる。 』
→『CSPを無視して他のWebサイトへデータを含んだリクエストを送ることができる。 』
とでもしときましょうよ。