Re: [CSP] Extensions and user script? (Some feedback)

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.

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) amount of 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.

-mike

[1]:
https://cs.corp.google.com/#chrome/src/chrome/renderer/chrome_content_renderer_client.cc&q=registerURLSchemeAsBypassingContentSecurityPolicy&sq=package:%5Echrome$&type=cs&l=242


On Aug 29, 2012 1:35 PM, "Odin Hørthe Omdal" <odinho@opera.com> wrote:

> Hello all :-)
>
> I've gotten some internal web site author feedback trying to implement CSP
> on a web email service that I'd like to share and discuss.
>
> There's of course a few minor things that will get better with time. Like
> browsers using prefixes and different implementations of different
> versions of the spec. As well as some potential bugs found, such as using
> an same-domain iframe with an email in it, and then rewriting links
> therein to do target=_blank, and it was suddenly blocked. They had to open
> up frame-src: * in order for the links to open. From my cursory reading of
> the spec, it does seem like this is in fact intended behaviour, but I'm
> not sure.
>
> The biggest problem however is the interference of pages' CSP policies
> when an extension goes mucking around the page doing whatever it likes to
> do.
>
> This is not the same as having a CSP-profile on the extension, as Chrome
> is doing, but the other way around:
>
>  Extensions can
>> inject arbitrary javascript, css into the page and modify the DOM in any
>> way. Depending on the CSP policy, those will potentially be blocked. The
>> most annoying thing is that those might break your extension or the page
>> in subtle ways because some things the extension does work (DOM
>> manipulations), but other things fail (scripts/css injection).
>> Additionally changes that do fail will generate heaps of false positive
>> feedback reports, making the reporting feature a pain to sift through
>> and work out "now is this a problem with my CSP poilicy, or is it some
>> extension the users installed that's trying to modify the page in some
>> way".
>>
>> I don't see any realistic solution to this. You'd have to track a whole
>> bunch of manipulations and changes to the DOM as either "done by the
>> page" or "done by an extension" to work out if they should be allowed or
>> not.
>>
>> So at first I thought "what a great idea", but after two days of messing
>> around and actually trying to use it, I decided that it might be
>> bordering on unuseable in the real world
>>
>
>
>
> I have not looked into it myself, but this is a very valid concern if we
> were to implement it in Opera. What have you that have implemented this
> already done about it? How does it work? Is really extensions crippled in
> such a way, do they have to think about it?
>
> --
> Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software,
> http://opera.com
>
>