Bogus CSP (Content-Security-Policy) directive violation for favicon when using img-src: 'self'
Reported by
jw...@jwatt.org,
Mar 7 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0 Steps to reproduce the problem: 1. Go to https://jwatt.org/ 2. See in devtools that csp-violation-reporter.php is loaded What is the expected behavior? csp-violation-reporter.php should not be loaded What went wrong? Chrome sends the following: { "csp-report": { "document-uri": "https://jwatt.org/", "referrer": "", "violated-directive": "img-src", "effective-directive": "img-src", "original-policy": "base-uri 'self'; block-all-mixed-content; default-src 'self' 'unsafe-inline'; form-action 'self'; frame-ancestors 'self'; plugin-types 'none'; report-uri /csp-violation-reporter.php", "disposition": "report", "blocked-uri": "https://jwatt.org/favicon.ico", "status-code": 0 } } When 'img-src' is set to 'self', https://jwatt.org/favicon.ico should not be reported as a directive violation since it has exactly the same origin as https://jwatt.org/ Did this work before? N/A Does this work in other browsers? Yes Chrome version: 56.0.2924.87 (Official Build) (64-bit) Channel: n/a OS Version: OS X 10.12 Flash Version: Shockwave Flash 24.0 r0
,
Mar 7 2017
(FWIW this confusion wouldn't have happened if the "document-uri" had contained the outer 'view-source' scheme.)
,
Mar 8 2017
Unable to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.3 using chorme version 56.0.2924.87 with the below steps 1.Go to URL https://jwatt.org/ 2.Open dev tools 3.Not observed file csp-violation-reporter.php in sources 4.Observed the error in console "Failed to set referrer policy: The value 'strict-origin-when-cross-origin' is not one of 'no-referrer', 'no-referrer-when-downgrade', 'origin', 'origin-when-cross-origin', or 'unsafe-url'. The referrer policy has been left unchanged." Jwatt@ Could you please confirm if anything missed here in triaging the issue. Request you please provide us any expected screen shot to triage the issue from test team end. Thanks,
,
Mar 8 2017
Hrm. I would have expected `view-source:` pages to be inert. It seems to me that it's a better idea to prevent the favicon request than to teach CSP to unwrap `view-source:` URLs (as that has some risk with regard to bypasses). Yoav, you know things about loading: do you happen to know where we kick off the favicon request, and whether we could stop doing so for `view-source:` URLs (or who to talk to? :) ).
,
Mar 8 2017
kavvaru: see comment 1 - you need to use view-source:https://jwatt.org/ in step 1. As an aside, I think I'm going to have to stop reporting or commenting on Chromium bugs. The reCAPTCHA thing is an absolute nightmare to pass!
,
Mar 8 2017
AFAIK Link based icons are loads are triggered from https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/LinkStyle.cpp?q=LinkStyle+package:%5Echromium$&l=369 (which is then piped through https://cs.chromium.org/chromium/src/content/renderer/render_view_impl.cc?q=didChangeIcon&l=1951 and seems to be getting the URLs from https://cs.chromium.org/chromium/src/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp?type=cs&q=iconURLs&l=557 ) I can't say that I know that code particularly well, and I don't know off-hand how favicons without a link are being fetched
,
Nov 10 2017
,
Feb 18 2018
,
Apr 17 2018
FWIW, I'd like to just slap a CSP: "default-src none" into View-Source pages, but I'm a bit afraid to explicitly because doing so mean that pages at View-Source will no longer show the proper favicon on the tab.
,
Aug 1
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by jw...@jwatt.org
, Mar 7 2017