Issue metadata
Sign in to add a comment
|
Content security policy is not honored for SVG images loaded as subresources
Reported by
wisniews...@gmail.com,
Aug 15 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Example URL: https://wtfismygs.com Steps to reproduce the problem: 1. Visit https://whatismygs.com 2. Notice that "WTF IS MY" in the logo is red. 3. Open the same SVG background-image on the h1 tag in a new tab using the devtools. 4. Notice that "WTF IS MY" has a gradient fill instead of being red. What is the expected behavior? The gradient fill of the SVG (id=j) should apply when the SVG is viewed as a background-image, as well as when viewed as a stand-alone document. What went wrong? Difficult to tell; perhaps it's due to the image being viewed as a background-image rather than a standalone document. The same SVG path element has a clip mask which is being referenced properly (id=k), but the fill on the same element is being ignored, almost as though its id cannot be found in the document (id=j). Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? No Safari (but not Edge or Firefox) Chrome version: 59.0.3071.115 Channel: n/a OS Version: Flash Version: The issue still exists in Chrome Canary 61 (tested on OSX). This issue was originally reported to webcompat.com: https://webcompat.com/issues/8870
,
Aug 15 2017
Pardon the typo in the first STR step: I of course meant https://wtfismygs.com I've also filed an equivalent Safari bug: https://bugs.webkit.org/show_bug.cgi?id=175587
,
Aug 15 2017
This is something to do with mix-blend-mode. Here's a smaller testcase: Compare: output.jsbin.com/lotevip/quiet To: https://wtfismygs.com//assets/logo-e142ffb48948714e1d103cf398ca5bd13e7be12fb302fe41458243648ff27e05.svg These should look the same but do not.
,
Aug 15 2017
Ah, this is due to CSP headers sent from the server: content-security-policy:default-src 'none'; block-all-mixed-content; connect-src 'self' wss:; img-src 'self' data: www.google-analytics.com; script-src 'self' www.google-analytics.com 'sha256-5/w5wEj5C2EFROmL8m0pVUE+CraUgYqRYT1b/0vrU70='; style-src 'self' 'sha256-vRzNr8OXAI2PQ1gJpDovs4Q1XX0wpMl7zKd9MQyJpTw='; upgrade-insecure-requests If you open the image by itself, this is in the console: Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'sha256-vRzNr8OXAI2PQ1gJpDovs4Q1XX0wpMl7zKd9MQyJpTw='". Either the 'unsafe-inline' keyword, a hash ('sha256-NyioQWdrkFj0FLxvvrUJUEXawMDDkqnbWZTLjbBW6jQ='), or a nonce ('nonce-...') is required to enable inline execution. It appears that we are not honoring the CSP headers when loading this as an <img>, whereas we do when loading it in its own document. Security team, can you look into this?
,
Aug 15 2017
,
Aug 15 2017
wisniewskit, thanks for taking the time to file this. The image has style="mix-blend-mode:overlay" in it but the server's CSP headers are configured to ignore inline styles. I think this is Chrome's bug that we are not honoring your CSP headers and are incorrectly applying this style. That said, I think you probably don't want this behavior and you can just remove style="mix-blend-mode:overlay" from your image to workaround this bug.
,
Aug 15 2017
Based on #c4, this sounds the same as issue 378500 (CSP going missing due to SubstituteData trickery most likely.)
,
Aug 15 2017
,
Aug 15 2017
Thanks pdr, I'll update the webcompat.com report with your comment. If our team can, we'll try reaching out to the site authors to pass along your suggestion. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 Deleted