Re: CSP and inline styles

Thanks for your answer, Mike!

> 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. :)

I'm not sure this is the right analogy here. Inline styles are not
inherently dangerous. Only unwanted, UG unfiltered content ones are.

> A developer can choose to allow inline style by adding 'unsafe-inline'

True, but it would be a shame if a "performance best practice" would also
be a "security worst practice". While trade-off is sometimes necessary,
it's better for everyone if we'd avoid imposing this choice on developers.

> I don't think it's safe to assume that developers won't echo user-controlled
data in a document's head

In that case, I take back my proposal to enable inline styles in the head
as the default option.

> 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

I'd love to understand why adding scope adds significant complexity &
results in a performance hit. Can you elaborate?

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

Great! The main use case IMO would be to enable "legitimate" inline styles
and avoid a performance hit before the page's initial paint.

My issue with "nonce" is that it requires server side logic (coordinating
between HTTP headers and the HTML templates), and cannot be implemented on
a static server, even if the developer can add CSP HTTP headers. It is much
better than nothing, but I'm not certain it'd be easy enough for developers
to use.


A different random thought - correct me if I'm wrong but there are 3 main
dangers from injected styles:
* "javascript:" scheme URL or equivalent "data:" URIs
* "expression()" - Not sure it is still relevant past IE8
* Defacing

While we can't limit defacing without blocking the entire style, we can
limit "javascript:" URLs and "data:" URIs that are not images/fonts.
It would enable permitting inline (or other) styles, while blocking any
scripting that could result from these styles.
I'm not certain it is beneficial, but worth considering IMO.

Yoav




On Sat, Dec 29, 2012 at 10:45 AM, Mike West <mkwst@google.com> wrote:

> 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
>