Content Security Policy not expected to apply to native views
Reported by
timotij...@gmail.com,
Sep 8 2016
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36 Example URL: https://avatars2.githubusercontent.com/u/81392 Steps to reproduce the problem: 1. View an image served with an HTTP response header like ` Content-Security-Policy:default-src 'none' ` What is the expected behavior? What went wrong? Chromium uses inline styles in its built-in viewer for images, which are subsequently blocked by CSP even though. As such, the same image page looks different than expected. For example, it features a white margin along the edge of the page (default margin of 8px in the user agent stylesheet). This can be confusing to users since normally this is not the case when viewing images and can be mistaken as being part of the image. The following 3 errors are in the shown in the console: 1. Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'none'". Either the 'unsafe-inline' keyword, a hash ('sha256-H/s/dWGkGDaCkKqmo0VNeHrTgvJjinI5uvu7UmY6EB8='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback. 2. Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'none'". Either the 'unsafe-inline' keyword, a hash ('sha256-15TqmL1cbLqMXH1nK4EwD191NLSXxlbnYzFAfbG/xp8='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback. 3. Refused to load the image 'https://avatars2.githubusercontent.com/favicon.ico' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback. * Error 1 is for <body style="margin: 0px;"> * Error 2 is for <img style="cursor: zoom-in;" ..> * Error 3 is for the implicit subresource of favicon.ico Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2853.0 Channel: canary OS Version: OS X 10.11.4 Flash Version: Firefox has no errors in the console when viewing images. It has no inline styles for its built-in image view HTML and appears to load the page styles from an internal file over a custom "resource://" scheme which appears to be whitelisted and works despite of CSP. (Presumably this scheme is secured in such a way to only work from pages generated by the browser itself.) It also uses the image itself as the favicon in the browser tab (it does this when viewing other images as well, not just when blocked by CSP).
,
Sep 9 2016
Routing to SecurityFeature.
,
Sep 9 2016
Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for Google Chrome Canary Version - 55.0.2854.2 This is a Non-Regression issue existing from M30 - # 30.0.1549.0
,
Sep 9 2016
,
Sep 12 2016
Hrm. I can understand the confusion on the one hand, but on the other, it's not clear how an origin is otherwise supposed to protect itself against plugin execution. That is, I think it's a feature that `object-src 'none'` blocks an `.swf` file's execution even when loaded in the top-level. Given that, `img-src 'none'` blocking images seems like a reasonable extension for consistency. CCing Dan from Mozilla for thoughts about Firefox's behavior.
,
Feb 23 2017
Dan has no opinion, apparently. :) Chrome's behavior here is clearly inconsistent. We should either block the image entirely (as `default-src 'none'` should block all images), or we should not apply the policy to the resource. CCing others who might have opinions.
,
Feb 23 2017
,
Feb 23 2017
Sorry, I didn't see the original request. It seems sucky to let a site use CSP to block inspecting an individual image. There are lots of other ways to do that, though, such as sending the wrong content-type with a 'nosniff' header or a content-disposition: attachment if that's really their intent. If you're going to display the main image itself the other browser-supplied goop around it to make it pretty should be immune to the site's CSP. Much like the CSP spec says we should try to make user-chosen add-ons work, default browser UX seems even more so. Same should be true for <audio> and <video> content: the site's CSP should not suppress the browser-supplied player controls if you're going to handle that content (which I think users would want). If I start from the other end, plugin content, I come to the opposite conclusion--OMG no!--primarily because of the consequences for unwanted scriptable plugins running in the victim's domain. Is it OK to treat these two types differently? Browser-handled content vs plugin content?
,
Mar 6 2017
,
Sep 12 2017
The broken styling resulting from this can actually lead to usablity issues, e.g. the audio player is seemingly stuck in a weird position and cannot be controlled. This is with a file-host which uses "default-src https:", leading to 'Refused to apply inline style because it violates the following Content Security Policy directive: "default-src https:".' IMHO, built-in web browser UI features should definitely not be affected by CSP. That you choose to center images with CSS is an implementation-specific detail.
,
Nov 10 2017
,
Feb 18 2018
|
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by timotij...@gmail.com
, Sep 8 2016639 KB
639 KB View Download
865 KB
865 KB View Download