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.
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).
そもそも 'unsafe-inline' は危険なので使うべきではないとW3C勧告に書かれている (スコア:3)
CSP を導入しているけど、インラインスクリプトが使えないと不便だからか 'unsafe-inline' を許可しているサイトも多いですが、危険だし、中途半端で美しくないポリシーだと思います。
6. Content Security Policy Directives [w3.org] より
'unsafe-inline' は XSS 攻撃を可能にするので、いずれのケースであっても、指定すべきでな
そういう問題ではない (スコア:1)
Re: (スコア:1)
攻撃者が自分のサイトに設置するんなら最初からCSP自体設定しなければいいのでは。
今回の話は'unsafe-inline'な設定の標的サイトに対して、攻撃者がXSSな投稿を行い、
それをEdgeで踏んだ場合に、親コメントに有るような小細工無しで
「window.open()
→document.write()
→CSP未設定なabout:blank経由で任意のサイトへアクセス
→CSRFまたはXSSにより取られたデータの外部送信」
が発生するって脆弱性だと思うのですが。
Re: (スコア:1)
Re:そういう問題ではない (スコア:2)
headless さんの解釈だと、攻撃者が、攻撃者の管理するサイトの CSP に 'unsafe-inline' を指定し、そこから about:blank を開くことで、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) を回避して、異なるオリジンのリソースとやり取りし放題になる脆弱性だということでしょうか？
もし、そうだとしたら、例えば任意のドメイン名のWebサイトからCookieを盗めることになり、世界中が大騒ぎになってますよ。
の2つを勘違いされているようです。今回の問題はあくまでも後者です。
その根拠は、TALOS-2017-0306 - Cisco Talos [talosintelligence.com] の下記の記述
異なるオリジンへのネットワークアクセスの仕様 [mozilla.org] を理解していれば分かりますが、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) では、別のオリジンからの画像の読み込みはブロックされません。それがブロックされると書かれているので、あくまでも Content Security Policy (CSP) による制限の話です。