webRequest: no events are fired for CSP-violating resources
Reported by
ch...@chrisn.me.uk,
Aug 18 2016
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce the problem: 1. Install the demo extension (files attached), which prints webRequest events to the console. 2. Open the extension's background page. 3. Visit the MWE at https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/ - this page contains an image whose loading is blocked because it violates the document's Content-Security-Policy HTTP header. 4. Note that no webRequest events are fired for https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/csp-violation.gif, the resource that was blocked for violating the CSP header. What is the expected behavior? Two webRequest events should be fired for the image: onBeforeRequest, followed by onErrorOccurred. (I'm not sure what the error reason ought to be in the onErrorOccurred event, but it'd be helpful if Chromium somehow indicated that the request was aborted because of a CSP violation, like it does in the DevTools pane: see below.) What went wrong? No webRequest events are fired at all for the image. Did this work before? No Chrome version: 52.0.2743.116 Channel: stable OS Version: Flash Version: Shockwave Flash 22.0 r0 I'm filing this as a bug rather than a feature request for two reasons: 1: The blocked image has its own row in the Network tab of the DevTools pane (http://i.imgur.com/Nb85bAF.png). It seems unusual to make information about the blocking of a resource available via the GUI, but not via the extensions API. 2: A similar situation arises when Chromium internally rewrites a http:// URL as a https:// URL when the URL's origin appears in Chromium's HSTS preload list. To the webRequest API, Chromium's internal rewriting of the original http:// URL looks like a redirect: a full webRequest event cycle occurs (onBeforeRequest -> onBeforeRedirect), complete with a Chromium-generated HTTP status code 307 in the onBeforeRedirect event data. This is really useful information, and given that extensions already receive this information for HSTS URL rewrites, it'd be great to receive similar webRequest events for CSP-violating resources.
,
Aug 19 2016
Tested this issue on Ubuntu 14.04 using chrome latest stable M52-52.0.2743.116 by following steps mentioned in the original comment. By opening both the links from step-3 & 4 observed the webRequest events are fired in the background page. chris@ - Attaching screen-cast for reference, Could you please confirm is this is the expected behavior of this issue?
,
Aug 19 2016
Thanks for that screencast - there's been a misunderstanding, perhaps my bug report wasn't clear: csp-violation.gif is an image embedded in the page at https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/, but it's not loaded because doing so would violate the CSP header served along with that document: Content-Security-Policy: img-src 'none'; report-uri https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/csp-report.cgi; The screenshot at http://i.imgur.com/Nb85bAF.png shows how Chromium indicates this blockage graphically ("(blocked:csp)" in the Network tab of the DevTools pane), but extensions aren't given the same information.
,
Aug 22 2016
Requesting someone from security team to look in to this issue. Thanks!
,
Nov 14 2016
Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.6 using chrome version 54.0.2840.99 and canary 56.0.2918.0. Please find the bisect information as below Narrow Bisect:: Good :: 47.0.2500.0 --- (official build 347062) Bad :: 47.0.2501.0 -- (official build 347299) Change Log:: https://chromium.googlesource.com/chromium/src/+log/7459cf2f2c78018c855414052523805e3e423149..6328f3f47112937ea6eb7fcb6f2c3efce593538f Possible suspect:: https://chromium.googlesource.com/chromium/blink/+/b2873fd5425a89d70f5483fda4ce7d765137fe8a dgozman@ could you please look into this issue if it is related to your change,else please route this to an appropriate dev person. Thanks,
,
Nov 14 2016
DevTools behavior is definitely good in this case - we show detailed information to the user. Over to extensions team. Note this is not a regression - DevTools behavior improved while api didn't change.
,
Nov 18 2016
,
Nov 20 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 28 2017
This is still a problem, and still ought to be fixed.
,
May 15 2018
,
Nov 9
So I think what happens is that these requests are blocked at the blink/ layer and so they never reach the browser process. Hence there are no web request events generated for these. And I can't see how this can be fixed given the way things are currently structured. Also, as the documentation (https://developer.chrome.com/extensions/webRequest) says the web request API is meant to serve as an abstraction of the Chrome's network stack, this is probably WAI since there isn't an actual network request made for these resources. I wonder if it's possible to detect this somehow using content script injection. Since I don't see us fixing this anytime soon for the web request API, closing it as WontFix. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by ligim...@chromium.org
, Aug 18 2016