- From: Mike West <mkwst@google.com>
- Date: Mon, 10 Feb 2014 12:12:43 +0100
- To: David Bruant <bruant.d@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=cRRa6yMEK+NS5T5fkhcSxcXddGQuR_-w9JWD0Qma6Dgg@mail.gmail.com>
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