W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2014

Re: Holiday changes to the CSP 1.1 editor's draft.

From: Ian Melven <ian.melven@gmail.com>
Date: Tue, 18 Feb 2014 15:48:05 -0800
Message-ID: <CA+0m=FeoOm=VBWR7HEoB-BXX1NxWtss8i0gq7xok4C_5aQrBjg@mail.gmail.com>
To: Ben Toews <btoews@github.com>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hullo W3C friends,

Mike : i agree - it's silly if everyone just has to add unsafe-eval to
style-src and make the restriction essentially useless - this was
definitely a concern that was discussed around this restriction (and even
around style-src unsafe-inline as well, since there was a feeling many
sites and especially apps were going to need it).

Ben : there's some background on the rationale behind unsafe-eval for
style-src in a couple of Mozilla bugs :
https://bugzilla.mozilla.org/show_bug.cgi?id=873302 which is the bug to
restrict CSSOM calls using style-src: unsafe-eval and
https://bugzilla.mozilla.org/show_bug.cgi?id=763879 which was the original
bug to block 'inline styles' as part of the implementation of the CSP 1.0
spec.

I brought the discussion to this list at the time, which you can see at
http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0097.html if
you're interested.

I already raised a concern about breakage with this restriction earlier in
this thread, which I now think has to be considered as a given due to
affecting JQuery. My personal opinion at this time is that the limited
benefit of blocking CSSOM access from already whitelisted scripts is not
worth the fact of breakage and that the existing unsafe-inline
restrictions, particularly on the style attribute, address the much more
likely injection vector.

cheers,
ian



On Mon, Feb 17, 2014 at 10:31 AM, Ben Toews <btoews@github.com> wrote:

> Mike,
> Thanks for addressing this in Blink. We just removed unsafe-eval from our
> style-src. We hadn't been planning on locking down our style-src too
> tightly to begin with. Adding unsafe-eval wasn't a huge concern and we can
> add it back if we need to. We are a bit unclear though on what this was
> intended to protect against. It seems that none of the browsers that
> support CSP have any of the old JavaScript-in-CSS problems. Was this source
> just giving control for the sake of giving control, or are we missing
> something? Thanks!
>
> --
> Ben Toews
>
> On Monday, February 17, 2014 at 3:13 AM, Mike West wrote:
>
> On Thu, Jan 16, 2014 at 11:21 AM, Mike West <mkwst@google.com> wrote:
>
> I'd suggest the following: I'll implement the CSSOM change behind the flag
> in Blink, turn it on locally, and browsing around on Facebook and Github.
> If they break, I'll email folks to see if they can easily add 'unsafe-eval'
> to their `script-src` directives.
>
>
> I added this change to Blink a week or three ago. It broke quite a bit
> more than I expected. As it turns out, jQuery relies on 'cssText' for a
> number of internal checks and some functionality.
>
> GitHub added 'unsafe-eval' quickly, but it looks like we'll end up in a
> situation where 'unsafe-eval' is whitelisted by everyone who sets a
> 'style-src' directive. I'm not sure this is a change we should make; I've
> reverted the functionality from Blink so that I'm not breaking chunks of
> the web for folks who have the "Experimental Web Platform Features" flag
> flipped.
>
> -mike
>
>
>
>
Received on Tuesday, 18 February 2014 23:48:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC