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

Re: CSP and inline styles

From: Mike West <mkwst@google.com>
Date: Sat, 29 Dec 2012 10:45:43 +0100
Message-ID: <CAKXHy=d+w2iMwGC-KOmwn_St005xdh62R_fTJD3H31tWjtomxQ@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi Yoav! Thanks for pinging the list about this.

On Fri, Dec 28, 2012 at 2:58 PM, Yoav Weiss <yoav@yoav.ws> wrote:
> Inline style tags are an important part of Web performance best practices.

I'm sure my car would go much faster if I strapped a rocket engine to
the roof, but speed isn't the only relevant consideration. :) There's
sometimes a choice to be made between risk and performance.

It's important to note that CSP doesn't, in fact, ban inline style. A
developer can choose to allow inline style by adding 'unsafe-inline'
as a whitelisted source of style, though of course that increases her
risk of some forms of XSS attack. That's a choice she is in the best
position to evaluate.

>  * Allow inline style in the pageís `head`, possibly using an
> `unsafe-inline-in-head` directive
>   - Iím not certain, but I think itís safe to assume that user-generated
> content does not get included to the pageís `head`, at least in most cases.
>   - The same directive can probably be beneficial for scripts as well.

I don't think it's safe to assume that developers won't echo
user-controlled data in a document's head. Twitter, for instance,
echos the username in the ID of two inline style blocks (not to pick
on Twitter; that was just the first site I checked, and it looks like
they're being careful about escaping). Debug comments in a document's
head are also fairly common, as well as advertisement setup code that
encode the current URL.

Still, the idea of scoping the whitelist to a document's head is
interesting. I'm not sure the complexity is worth the benefit, but I
do think it's worth some discussion. Some quantification of the
performance impact

>  * Allow a nonce to enable inline styles, even if inline styles are blocked
> by default.
>   - Since this is permitted for scripts, I donít see any security downsides
> here.

If there's a good use case for `style-nonce`, it sounds reasonable to add it.

> Please note that a ďnonceĒ based solution will make it impossible for some
> Web developers to include only certain inline scripts and styles, since they
> only have control on their siteís client-side code and a random nonce
> requires server-side logic.

If developers don't have access to their server, then they're going to
have a hard time using CSP in general; the preferred delivery
mechanism is an HTTP header, and WebKit is the only engine that
implements the still-experimental <meta> delivery mechanism.

-mike
Received on Saturday, 29 December 2012 09:47:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 29 December 2012 09:47:01 GMT