Re: [CSP] Clarifications regarding the HTTP LINK Header

I wonder a bit how much this actually matters for the guarantees we're trying to make for CSP?

If I prefetch something that is later denied to be included / transcluded into a page via CSP, have I violated the policy?

Even if we decide to use CSP for confinement (which it presently makes no strong guarantees of) is link fetching that happens before the instantiation of a resource in the scope of that confinement?

I think an example of an actual vulnerability that we would care about addressing would help me reason about this better.

-Brad

From: Ilya Grigorik <ilya@igvita.com<mailto:ilya@igvita.com>>
Date: Friday, November 14, 2014 at 11:36 AM
To: Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>>
Cc: Brian Smith <brian@briansmith.org<mailto:brian@briansmith.org>>, Boris Zbarsky <bzbarsky@mit.edu<mailto:bzbarsky@mit.edu>>, "public-webappsec@w3.org<mailto:public-webappsec@w3.org>" <public-webappsec@w3.org<mailto:public-webappsec@w3.org>>
Subject: Re: [CSP] Clarifications regarding the HTTP LINK Header
Resent-From: <public-webappsec@w3.org<mailto:public-webappsec@w3.org>>
Resent-Date: Friday, November 14, 2014 at 11:38 AM

On Thu, Nov 13, 2014 at 7:05 PM, Brian Smith <brian@briansmith.org<mailto:brian@briansmith.org>> wrote:
On Thu, Nov 13, 2014 at 8:56 AM, Ilya Grigorik <ilya@igvita.com<mailto:ilya@igvita.com>> wrote:
> On Wed, Nov 12, 2014 at 4:24 PM, Brian Smith <brian@briansmith.org<mailto:brian@briansmith.org>> wrote:
>>
>> 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.

The syntax ("http-equiv") literally says 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.

Developer tools should warn whenever anything other than "<!DOCTYPE
html>", "<html>", "<head>", or "<meta charset=...>" appear before
"<meta http-equiv=Content-Security-Policy>", regardless of whether it
applies to Link headers.

Sounds reasonable. Not sure what the behaviors are today, but if that's not the case, then worth opening some bugs for it.

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

I mostly agree with you. But, don't you already need to wait for <meta
name=Referrer> so that you know which Referer header to send in your
HTTP requests for prefetches that result from HTTP LINK? That is,
doesn't <meta> Referrer have the same problem?

Yep, I guess it would.

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

The way to make this clear would be to add a note to the HTML
specification, the CSP specification, and the resource hints
specification, and then also have developer tools warn when HTTP LINK
and CSP <meta> are used together.

+Referrer Policy.. and, sounds like a plan! Having some shared boiler plate would make things easier. Perhaps something like...

-----
To guarantee that the specified policy is applied before any resource requests, the site SHOULD specify the policy via an appropriate HTTP response header. The user agent MUST process all response headers, and apply all relevant policies, prior to initiating any resource requests - e.g. fetches initiated by Link, or other mechanisms. If the policy cannot be specified as a response header, the developer SHOULD specify it via a <meta> tag and place it as early as possible in the response body. The user agent MUST apply the specified policy for all fetches that follow the <meta> policy declaration.

Note that <meta> policy is applied after HTTP response headers are processed, so it may not apply to fetches initiated via HTTP response headers - e.g. Link, or other mechanisms. If the site is using such mechanisms, it SHOULD specify its policies via HTTP response header.
----

Or some such... I think it covers all the cases?

ig

On Fri, Nov 14, 2014 at 1:22 AM, Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>> wrote:
On Fri, Nov 14, 2014 at 4:05 AM, Brian Smith <brian@briansmith.org<mailto:brian@briansmith.org>> wrote:
> The syntax ("http-equiv") literally says they are equivalent!

Yes, but the feature is defined in a very different way. The name is
legacy, as so many names throughout the platform. E.g. <meta
http-equiv=access-control-allow-origin content=*> must not work.


--
https://annevankesteren.nl/<https://urldefense.proofpoint.com/v1/url?u=https://annevankesteren.nl/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=ZAZdDZMip0EhvKHV%2FICccfepRCCStNSVoef70zdwdqA%3D%0A&s=3c2f9586553ecb99b57318e06250ebb8787c6a6b4c94cbda3dc52499b288d7a3>

Received on Monday, 17 November 2014 23:15:35 UTC