- From: David Bruant <bruant.d@gmail.com>
- Date: Thu, 30 Jan 2014 17:48:58 +0100
- To: Mike West <mkwst@google.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <52EA827A.4010808@gmail.com>
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.
David
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=704320#c16
Received on Thursday, 30 January 2014 16:49:29 UTC