- From: Odin Hørthe Omdal <odinho@opera.com>
- Date: Tue, 25 Sep 2012 16:41:07 +0200
- To: public-webappsec@w3.org
[Oops, I totally forgot this email that's been lying around. I probably wanted to shorten it, but I'll just send it as-is. :D ] On Wed, 29 Aug 2012 14:13:19 +0200, Mike West <mkwst@google.com> wrote: > It is a problem (though I certainly don't consider it fatal), and I > haven't > yet seen a truly effective approach to avoiding it completely. > > In Chrome, we've addressed it to a limited extent by bypassing CSP > checks[1] for resources that come from the 'chrome-extension:' and > 'chrome-extension-resource:' schemes. This means that extensions > injecting > only _their own_ resources will be more or less unaffected by a page's > CSP > directives (with the notable exception of 'sandbox', 'unsafe-inline' and > 'unsafe-eval'). The experimental 'script-nonce' directive might be a > mechanism for whitelisting extension's inline scripts as well. That seems like a good way to solve a bit of the problem. Although I can think of places where the sandbox could make life hard for some extensions. > We don't have a good solution for extensions that want to inject > resources from third party servers. Images are the biggest issue here. > For the moment, we're not planning on undertaking the (large) amountof > work that would be necessary to support the use case. > > As an aside, this problem was actually an issue for WebKit's devtools as > well, as it uses `eval` to inject code from the console into the page's > context. There, they've done some tricky work to enable `eval`, run some > code, and then disable `eval` again. OK, and that's where things are most interesting. User JS (scripts running at the page, "greasemonkey" in Firefox) would seem to be broken by this. Also some extensions, like e.g. an OpenStreetMap extension that shows a map next to addresses (or similar). What would the behavior for that extension be on a web site that has CSP? E.g. disabling image loading from other sites would break it. The easiest way out might be to just disable CSP for the site if an extension wants to inject a userscript into it. I think it's a very bad idea to cripple extensions. Current browsers send violation reports based on these "violations". That's noise. Our internal webdev team didn't like it because of the false positives they got due to extensions. I would guess in a real-world setting it'd quickly feel like fighting spam today. You have to go through lots of noise in order to find something actually useful. Another dimension is the privacy issue. Your browser is effectively leaking information about what extensions you've got installed. Or maybe even your private hash if the extension does a GET with that security token in the URL. I would guess that can be easily exploited other ways too and such an extension would be considered badly written, but the main issue of reporting still stands. These issues can arguably be said to be just a matter of implementation, but the spec has to be implementable, and it would make sense for us to actually think about what problems it's going to cause. I guess quite a lot of extensions will get broken by this. Thankfully few websites use CSP right now, but having extensions break is a rather drastic step to take. It might hurt CSP if the _real_ implementation cost is too high for anyone to prioritize it. In two ways I can see: If I'm doing a good-guy website, I won't really be able to use CSP because it might interfere with my users' extensions. I don't want that. And me, as a user, would probably just turn the whole of CSP off if it breaks my extensions/userscripts. :-) So, more thoughts? Is external images really used so little that noone will really feel any impact on it? Are we not worried about giving CSP a bad name/reputation? Will writing extensions be made harder by this? -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Received on Tuesday, 25 September 2012 14:43:57 UTC