Re: [CSP] Clarifications regarding the HTTP LINK Header

On Wed, Nov 12, 2014 at 4:24 PM, Brian Smith <brian@briansmith.org> wrote:

> On Wed, Nov 12, 2014 at 3:43 PM, Ilya Grigorik <igrigorik@gmail.com>
> wrote:
> > We already provide a mechanism to set the policy via HTTP headers, we
> just
> > need to clarify that any fetches initiated on behalf of HTTP headers
> (i.e.
> > Link) are subject to CSP, and that by definition to cover this case...
> CSP
> > policy should be provided as an HTTP header.
>
> It's quite a usability failure, though. We're saying "Hey, here's
> <meta http-equiv=Content-Security-Policy> to make CSP easier for you
> to use, but don't use it, because it's not equivalent to the HTTP
> Content-Security-Policy header."
>

I don't think we should claim that they are equivalent.

For best results you need to define your CSP policy as early as possible.
Specifying it an HTTP header is the best route, as it guarantees that the
policy can be parsed and applied before any response body bytes are
processed. The second best option, if you can't use the HTTP header route,
is to provide an equivalent policy via <meta>, which should be placed as
early as possible in the document.

Perhaps, instead, we should require the browser to look for <meta
> http-equiv=Content-Security-Policy> during prescanning, and do
> prescanning before processing any LINK headers? That's much better
> usability. This would make prescanning required, and it would require
> an authoring requirement that <meta
> http-equiv=Content-Security-Policy> appear in the first 1024 bytes,
> but it would solve a lot of unresolved and/or unfortunately-resolved
> issues with CSP <meta>. What do you think?
>

I don't think we want to get into the business of "must be in first X
bytes" -- this, by itself, is a usability problem. Similarly, requiring
that we wait for <meta> would, once again, force proxies to start flushing
fake head sections and doing other funny business.

We should just make it clear that if you're using Link to initiate fetches,
and you use CSP, then your CSP policy should be provided as an HTTP
header... which is a security best practice anyway.

Could you please update the resource hints draft to add a requirement
> that all <meta http-equiv=Content-Security-Policy> elements be
> converted into Content-Security-Policy header fields whenever a link
> within the HTML document is converted to a HTTP LINK header?
> Otherwise, the resource hints spec isn't really CSP-friendly.
>

Will do, if you want to follow along:
https://github.com/w3c/resource-hints/issues/16

ig

On Wed, Nov 12, 2014 at 6:19 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 11/12/14, 7:24 PM, Brian Smith wrote:
>
>> Perhaps, instead, we should require the browser to look for <meta
>> http-equiv=Content-Security-Policy> during prescanning, and do
>> prescanning before processing any LINK headers?
>>
>
> What would the latter mean, exactly?  Or more precisely, can you define
> what "prescanning" means here?
>
>  This would make prescanning required, and it would require
>> an authoring requirement that <meta
>> http-equiv=Content-Security-Policy> appear in the first 1024 bytes,
>>
>
> This seems like a failure mode where just managing to inject some bytes
> you don't even control at the beginning of the document disables CSP...
>
> -Boris
>
>