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

Re: Processing of meta element

From: David Bruant <bruant.d@gmail.com>
Date: Tue, 11 Feb 2014 23:23:35 +0100
Message-ID: <52FAA2E7.1080503@gmail.com>
To: Mike West <mkwst@google.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Le 07/02/2014 15:31, Mike West a écrit :
> On Thu, Jan 30, 2014 at 8:48 AM, David Bruant <bruant.d@gmail.com 
> <mailto: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).
Another option to this part is to send no Referer in the cross-origin 
HTTP requests sent via the look-ahead parser until either a CSP <meta> 
or </head> is found.
It might actually be web-compatible.
The only downside is the non-determinism it creates (across refreshes, 
the same ressource may or may not have the header in the request), but 
maybe it doesn't matter.

David
Received on Tuesday, 11 February 2014 22:24:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC