- From: Mike West <mkwst@google.com>
- Date: Fri, 7 Feb 2014 15:31:53 +0100
- To: David Bruant <bruant.d@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=c1o6SH4WeT5BW0w-xy6JC4XVvhC7Rhj3dezmfCNJ11Ug@mail.gmail.com>
Hi David, sorry for the delayed response. It's been a rough week... On Thu, Jan 30, 2014 at 8:48 AM, David Bruant <bruant.d@gmail.com> wrote: > Le 30/01/2014 16:53, Mike West a écrit : > > Hey David, thanks for this feedback. It's helpful. > > In my mind, the <meta> bits of the CSP spec are "best effort" rather > than super-reliable restrictions. > > oh... is it required to be any reliable at all, then? > Of course. Once it's parsed, it should have exactly the same effect as the HTTP header. "Once it's parsed", however, leaves a bit window in which it shouldn't be expected to be effective. > 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. It's currently not the case for referrer-in-meta-elements, however. Not in Blink (though I believe Mozilla has historically had concerns about this). > nor do I think it would be effective. For example, a <script> in the > <head> might do some exciting 'document.write()' wizardry that injects > content we should care about. Unfortunately, I doubt that's an edge case. > > To quote Henri Sivonen [1]: "authors who are silly enough to > document.write [their CSP meta] are on their own.". The related CSP won't > apply for requests sent before the script is executed, but authors had the > choice to output it directly as a meta or document.write they and chose > really badly. > Practically, I agree with you. The less document.write, the better. > 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. 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 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. > 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. :) > I strongly disagree with the idea of JS-initiated CSPs. When GWT will have > been updated to support CSP via header or parsed <meta>, it will only be > useful for attackers. > I honestly don't see how injecting CSP is useful to attackers. Again, if they can inject a CSP, they could equally well inject "<script src=' http://evil.com/evil.js'></script>" to much greater effect. > I've added a note to that effect in > https://github.com/w3c/webappsec/commit/dd4c1d7509e2af0ca341bd844ba2632a2b164bd7to make that intent explicit. WDYT? > > I prefer it because it's explicit. Thanks. > Great, thanks! -mikd
Received on Friday, 7 February 2014 14:32:41 UTC