Re: Processing of meta element

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. 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> 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>. I'm happy to add that as a note to the spec if
you think it would be helpful?

[1]:
http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document's-address

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

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

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


> 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). I've added a note to that effect in
https://github.com/w3c/webappsec/commit/dd4c1d7509e2af0ca341bd844ba2632a2b164bd7to
make that intent explicit. WDYT?

--
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 Thursday, 30 January 2014 15:54:25 UTC