Re: Processing of meta element

On Fri, Feb 7, 2014 at 4:50 PM, David Bruant <bruant.d@gmail.com> wrote:

>  Le 07/02/2014 15:31, Mike West a écrit :
>
>  Hi David, sorry for the delayed response. It's been a rough week...
>
> No problem. No rush until it's shipped anyway ;-)
>

I want to ship yesterday. :)

Before diving back into the line-by-line, let's step back for a moment. My
understanding of your claim is that allowing injection of policy at runtime
is dangerous because:

a) Authors might imagine they have more protection than they do.
b) Clever attackers might use policy injection to attack a site/user.

Is that an accurate summary?

If so, my general response is:

a) I agree 100% that injecting a policy after "boot" is strictly less
effective than delivery in <head>, or as an HTTP header. I hope you'd agree
that it is also strictly more effective than having no policy whatsoever.
I'd much rather see authors who can't (yet) directly support HTTP-based
delivery have JS-based delivery as a stepping-stone to a more complete
implementation, than to see those same authors reject CSP completely
because it doesn't work with their framework out of the box.

b) I still don't understand what the attack vector is here. Again, CSP
injection seems very, very low on the list of things that an attacker would
want to do if they'd found a hole in your website that allowed them to
execute script.

With that in mind, I'd place the risk of JS-based injection quite close to
zero, and the benefit somewhere quite a bit above zero.

>  This is use-case #2 above. It's something I explicitly intended to
>> support (dumb or not :) ), based on feedback from GWT developers here at
>> Google.
>>
>>  IIUC GWT serves as server-side code and generates the client side. How
>> come it can generate the client code to create a meta element in JS, but
>> not the server-side part outputting a <meta> in HTML? This doesn't make
>> sense to me. Improving GWT seems like the proper course of action.
>>
>
>  The use case is something like this: the application spins itself up,
> loading a variety of JavaScript from a variety of sources.
>
> These sources are known ahead of time. Why can't it emit a <meta> or send
> the HTTP header before loading the JS? I can't see a good reason. Only
> ephemeral reasons like "it's hard to retrofit in GWT given the current
> design and assumptions". And I'm not sure current (!) GWT limitations
> should influence the design of CSP.
> Moving forward, new frameworks will (hopefully) make room to customize the
> CSP header and the header will be the only needed thing.
>

Frameworks that make use of 'eval()' and 'new Function' will have a hard
time doing this without whitelisting 'unsafe-eval'.


> Some (much!) of this JavaScript is loaded outside the document's <head>
> for performance reasons. Writing a <meta> element directly, therefore,
> isn't an option. The element must be injected into the document's <head>
> once the "dangerous" JavaScript has executed.
>
> I'm surprised by the last sentence. Inject potentially harmful JS and
> protect afterwards? Isn't this providing a false sense of security? Is it
> really doing a favor to GWT? ("I use CSP, I'm immune against XSS! ...
> woops, no I'm not")
>

1. We very explicitly position CSP as defense-in-depth. Using CSP does not
mean that you're immune to XSS. It is a powerful mitigation, but only one
of several you should be considering when structuring your application.

2. Obviously, we'd love for every developer to deliver a strong CSP policy
via an HTTP header. That would be ideal. There's a large distance, however,
between the ideal, and nothing. Missing the ideal shouldn't mean that we
offer nothing. We can and should support use cases that bring developers up
above zero protection.


> Again, maybe the way GWT starts the application is the thing to question.
> The design you describe to load the application is insecure. It's insecure
> in a way CSP is supposed to protect against. This really feels like a step
> backward.
>

If I could redesign GWT by fiat (and knew enough about the framework to do
so), I would. I cannot.

 I'm sorry, but I have to ask: is it a GWT-specific issue or do lots of
>> popular web framework lack the expressiveness?
>> If the problem is GWT-specific, it looks like Google is pushing a web
>> standard to work around one of its framework limitations.
>>
>
>  GWT developers are the ones I have access to, so that's the specific
> feedback I can offer.
>
>  Anecdotally, I can point to any number of libraries that require 'eval'
> or 'new Function()' in order to create and populate templates. This isn't a
> GWT-specific problem, as much fun as it would be if it was.
>
> unsafe-eval is enough for these use cases. As far as I'm concerned, I'll
> always use unsafe-eval as I don't believe it really provides any
> protection. A friend of mine worked on an emulator that JIT-compiles the
> ROM in JS with escodegen (interpreting never got him 60fps). He needs new
> Function.
>

That's a risk-reward tradeoff that you're encouraged to make with knowledge
of your own project. If you know your 'eval' usage isn't vulnerable, or
that 'new Function' doesn't interpret user-provided data, then more power
to you. :)

But that's not GWT's use case to use eval from what you describe.
>

Based on vague recollection, GWT needed both 'unsafe-inline' and
'unsafe-eval' to boot up the application. CSP 1.1 will make that less
problematic, but I don't think it resolves the problems entirely. In the
hopes of getting better data than "I think...", I've pinged GWT experts to
get more detail around the specific usage in today's GWT.


> <meta> already comes with the reserve that it should be placed as early as
> possible. I feel adding a JS way of doing things blurs the lines and the
> use cases outside GWT are still unclear.
>

Pulling back again, what do you think about this use case (that the spec
doesn't currently support)?

* I, as an author, want to lock down my page to the greatest extent
possible. Once I've loaded all the script I care about, I'd like to ensure
that no other script can run at all, even if it comes from an origin I
trust. I deliver my page with "script-src 'self' *.googleapis.com", and the
last script I load ends with an injection of "script-src 'none'".

Does that use case make sense? I think it does, though it's significantly
more paranoid than I'd expect most authors to be. Authors with reason to be
paranoid (banks?) might see it as worthwhile.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Monday, 10 February 2014 11:13:44 UTC