W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2012

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

From: Eric Chen <eric.chen@sv.cmu.edu>
Date: Wed, 29 Aug 2012 10:59:38 -0700
Message-ID: <CAF8haayBF2MCUTMA9vhrHOYS_A+hGmXiAczLjmLfhx5Q+z4mqw@mail.gmail.com>
To: "Hill, Brad" <bhill@paypal-inc.com>
Cc: Odin HÝrthe Omdal <odinho@opera.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
For CSP 1.1, if site authors use script-nonce then extensions can
technically bypass CSP by intercepting this nonce and inject scripts this
way. However, I don't think it is easy for browsers themselves to
temporarily disable CSP for extensions. Since the injected scripts might be
mangled with other scripts on the page and it's going to be hard to track
which script is legitimate.

On Wed, Aug 29, 2012 at 10:46 AM, Hill, Brad <bhill@paypal-inc.com> wrote:

>  I think extension mechanisms are quite implementation-specific Ė I donít
> object to discussing them on list, but Iím not sure that they need
> standardizing.   And new security UI associated with CSP is a third-rail I
> think we mostly all want to avoid.****
>
> ** **
>
> I think flipping your idea might be appropriate: browser implementers
> could provide APIs for an extension to inspect and temporarily disable the
> CSP for a resource it wants to modify.****
>
> ** **
>
> *From:* Eric Chen [mailto:eric.chen@sv.cmu.edu]
> *Sent:* Wednesday, August 29, 2012 10:41 AM
> *To:* Hill, Brad
> *Cc:* Odin HÝrthe Omdal; public-webappsec@w3.org
>
> *Subject:* Re: [CSP] Extensions and user script? (Some feedback)****
>
>  ** **
>
> What if we use a UI similar to mixed content, where we let users to
> re-enable their extensions.****
>
> On Wed, Aug 29, 2012 at 10:33 AM, Hill, Brad <bhill@paypal-inc.com> wrote:
> ****
>
> Extensions run with the intent and at the behest of the user.****
>
>  ****
>
> In a conflict between user intent and resource policy, user intent wins.**
> **
>
>  ****
>
> *From:* Eric Chen [mailto:eric.chen@sv.cmu.edu]
> *Sent:* Wednesday, August 29, 2012 10:29 AM
> *To:* Odin HÝrthe Omdal
> *Cc:* public-webappsec@w3.org
> *Subject:* Re: [CSP] Extensions and user script? (Some feedback)****
>
>  ****
>
> I'm not sure if this idea has been discussed before, but why not have a
> CSP policy that disables extensions? Disabling extensions entirely is
> probably better than half-breaking extensions.
>
>
> --
> -EC****
>
>  ****
>
> On Wed, Aug 29, 2012 at 4:34 AM, 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****
>
>
>
> ****
>
> ** **
>
> --
> -Eric****
>
> ** **
>



-- 
-Eric
Received on Wednesday, 29 August 2012 18:00:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 August 2012 18:00:06 GMT