- From: David Bruant <bruant.d@gmail.com>
- Date: Fri, 07 Feb 2014 16:50:36 +0100
- To: Mike West <mkwst@google.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <52F500CC.4010709@gmail.com>
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 ;-)
>
> On Thu, Jan 30, 2014 at 8:48 AM, David Bruant <bruant.d@gmail.com
> <mailto:bruant.d@gmail.com>> wrote:
>
> Le 30/01/2014 16:53, Mike West a écrit :
>
>> For CSP in general, we already state in the spec that authors
>> should place the tag as early in the document as possible to
>> reduce the risk of injection before it's parsed. I'd prefer to
>> simply make that "best effort" status more explicit. I don't
>> think that we can reasonably ask the user agent to delay requests
>> until after the entire <head> is parsed
> This wouldn't be necessary. Currently, it's clearly stated in CSP
> 1.1 that the first meta CSP takes precedence over other policies,
> so every request happening before reading a CSP meta doesn't have
> CSP applying
> to them, every requests happening after a meta CSP have the policy
> applying. Each request can be sent if everything above has been
> parsed. And that's probably already enforced in current engines?
>
>
> That's not enforced in current engines. Not Blink, in any event. There
> are basically two parsers: one "real" parser that blocks on script
> execution (for example), and another look-ahead parser that's used to
> speed up future requests predicatively by pre-resolving DNS for hosts,
> and pre-loading resources it thinks might be necessary.
>
> Blocking that second parser on an understanding of
> CSP-in-meta-elements might be possible.
Good to know. Note that you can pre-resolve DNS and even fetch from HTTP
cache as these don't leak the referrer. Admittedly, that's some
non-trivial additional engineering.
>
>> 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.
> 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")
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.
> 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.
But that's not GWT's use case to use eval from what you describe.
> Setting a CSP in JS is another attack vector for an attacker. If
> you didn't set a CSP (so, you're vulnerable to XSS :-) ), and a
> malicious script runs on your page, it can set an policy for you.
> For instance, it can forbid righteous script from reaching back to
> the server that served the page.
>
>
> This scenario is way outside the scope of what CSP can defend against.
> To be blunt: if an attacker can run script on your page, she can do
> anything at all. Injecting a CSP is, almost literally, the least
> effective attack I can imagine. :)
Yeah, sorry, a bit of bad faith on my side :-/
I'm still not sold. As far as I'm concerned, a protection taking effect
after DOMContentLoaded is almost equivalent to no protection and gives
at best a false sense of security. Maybe I'm too radical.
<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.
David
Received on Friday, 7 February 2014 15:51:06 UTC