W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2014

Re: Processing of meta element

From: David Bruant <bruant.d@gmail.com>
Date: Thu, 30 Jan 2014 17:48:58 +0100
Message-ID: <52EA827A.4010808@gmail.com>
To: Mike West <mkwst@google.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
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?

> We would clearly prefer that everyone send HTTP headers rather than 
> inlining their policies, but there are a few use-cases that make 
> sense. For example:
> 1. A project using a hosting service like GitHub Pages can't set HTTP 
> headers, but might (should!) be interested in setting a policy for itself.
> 2. Applications based on frameworks like GWT which rely on inlining 
> and `eval()` might wish to set a policy after "booting up". Ideally, 
> of course, these frameworks would understand CSP and work within 
> reasonable restrictions, but <meta> injection provides a stepping stone.
> With those in mind:
> On Thu, Jan 30, 2014 at 3:49 AM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>     Hi,
>     This is a bit of rehashing of discussions that was had starting at
>     [1] on <meta name="referrer">.
>     For the <meta> element, you need to:
>     * define how it works in relation to <base>
>     => I imagine it'll ignore it.
>     Related
>     http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-January/034520.html
> 'self' is indeed effected by <base>. That's the main reason we added 
> the 'base-uri' directive.
> I don't believe the 'referrer' directive is effected by base; it is 
> defined via Fetch's "determine 'referrer'" algorithm, which sets the 
> referrer to "the document's address"[1] of the fetching document. I'm 
> pretty sure that is not effected by <base>.
Ok, sounds good.

>     * browsers may keep parsing HTML and sending HTTP requests (for
>     link @rel stylesheet for instance) while the <meta
>     http-equiv="Content-Security-Policy"> is being handled in
>     parallel. Should the browser hold off all HTTP requests until the
>     meta-csp is fully parsed?
>     => I imagine yes, but the spec isn't 100% clear on the topic.
> For 'referrer' in particular: I'd suggest either ignoring the 
> 'referrer' directive in <meta> (as we do now for 'sandbox' and 
> 'report-uri'), or adding a note outlining the impact that 
> prerendering/fetching can have.
blah :-p It changes the conclusion of the other thread. If referred is 
removed from CSP meta, then, the addition of <meta name="referrer"> 
becomes necessary.
I think that there is a need for a page to *reliably* tell in-content 
how referrers should be handled for the sort of use cases you listed above.
CSP in meta seems like a good fit.

> 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?

> 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.

>     * What if I do the following in my page:
>     ````js
>     var metaCSP = document.createElement('meta');
>     metaCSP.setAttribute('http-equiv', "Content-Security-Policy");
>     metaCSP.setAttribute('content', myCSPPolicy);
>     document.head.appendChild(metaCSP);
>     ````
>     This is a dumb thing to do, but nothing prevents it in the current
>     spec unless I'm missing something. It should probably do nothing
>     and the spec should probably suggest caring only about
>     parser-inserted meta element.
> 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.
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.

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.

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.

>     Likewise, the spec should say that changes to an existing meta
>     will be ignored. It's at best implicit in the current prose.
> That's the intention, and I think the processing instructions there 
> ensure that it's the case (parsing the meta element is aborted if a 
> policy is being enforced).
True. I had missed that part.

> I've added a note to that effect in 
> https://github.com/w3c/webappsec/commit/dd4c1d7509e2af0ca341bd844ba2632a2b164bd7 
> to make that intent explicit. WDYT?
I prefer it because it's explicit. Thanks.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=704320#c16
Received on Thursday, 30 January 2014 16:49:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC