「AppleとGoogleが修正し、Microsoftが修正しなかった脆弱性とは」記事へのコメント

そもそも 'unsafe-inline' は危険なので使うべきではないとW3C勧告に書かれている

[Printable is bad. (38668)]

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

そういう問題ではない

[headless (41064)]

そもそも攻撃者はW3C勧告に従わないでしょう。今回の話は攻撃者が自分のサイトで'unsafe-inline'を指定するというものですよ。

Re:

[Anonymous Coward]

攻撃者が自分のサイトに設置するんなら最初からCSP自体設定しなければいいのでは。

今回の話は'unsafe-inline'な設定の標的サイトに対して、攻撃者がXSSな投稿を行い、
それをEdgeで踏んだ場合に、親コメントに有るような小細工無しで
「window.open()
→document.write()
→CSP未設定なabout:blank経由で任意のサイトへアクセス
→CSRFまたはXSSにより取られたデータの外部送信」
が発生するって脆弱性だと思うのですが。

Re:

[headless (41064)]

CSPが未設定だと同一生成元ポリシーに弾かれるのではありませんか。

Re:そういう問題ではない

[Printable is bad. (38668)]

headless さんの解釈だと、攻撃者が、攻撃者の管理するサイトの CSP に 'unsafe-inline' を指定し、そこから about:blank を開くことで、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) を回避して、異なるオリジンのリソースとやり取りし放題になる脆弱性だということでしょうか？

もし、そうだとしたら、例えば任意のドメイン名のWebサイトからCookieを盗めることになり、世界中が大騒ぎになってますよ。

• ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) による制限
• Content Security Policy (CSP) による追加の制限

の2つを勘違いされているようです。今回の問題はあくまでも後者です。

その根拠は、TALOS-2017-0306 - Cisco Talos [talosintelligence.com] の下記の記述

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).

異なるオリジンへのネットワークアクセスの仕様 [mozilla.org] を理解していれば分かりますが、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) では、別のオリジンからの画像の読み込みはブロックされません。それがブロックされると書かれているので、あくまでも Content Security Policy (CSP) による制限の話です。