mkwst: could you please help triage this? It's to do with preload in response headers.

Ilya, Yoav, who's responsible for `Link:`? I assume y'all thought about some of these concerns when designing the feature?

Marking this as low, as it's not clear to me how it creates any issues that `<img>` doesn't, but I'd be happy to bump it up if you can help me understand the attacks you're suggesting, shekyan@. :)

I own `Link:`, and its behavior has been specified in https://tools.ietf.org/html/rfc5988 and implemented in Firefox and Opera for years.

> - opens a new way for an attacker to trigger a stateful request on user's behalf to an arbitrary URL, which can be used as another CSRF or data exfiltration vector, or can be used as a replacement for tracking pixel

I don't understand how that would actually work in practice? who's the attacker here? how can they use response headers to exfiltrate data?

> - leaks origin of the document that requested the resource to a third-party

You can use the 'referrerpolicy' attribute on the Link header to avoid that. (doesn't currently work, but should. I tried to implement it but got pushback since Link headers and Fetch are not yet fully integrated)

> - cannot be blocked by CSP of the document. I expect connect-src to govern such requests

Should be blocked by CSP headers. If not the case, please file an issue.

- developer tools network tab confuses by showing initiator of the request to be the line in document that initiated the request to the resource with preload header.

ok

> Preload specification is ambiguous on this and doesn't specify what is a valid carrier for preload header, but I believe it should be only the response with the document. Firefox implementation seems to agree.

I disagree. There are many valid use-cases where you'd want to preload dependencies, etc.

>I don't understand how that would actually work in practice? who's the attacker here? how can they use response headers to exfiltrate data?

Attacker is the one compromising the third-party and inserting HTTP headers. While integrity metadata can ensure that the response body is what expected for certain MIME types, there is no existing control over unexpected headers, especially those that can trigger requests on embedder's behalf.

> - cannot be blocked by CSP of the document. I expect connect-src to govern such requests

I am not sure about this. Preload requests are not governed by CSP at all (both in the spec and the Chromium implementation), no matter who the carrier is. @mkwst, WDYT? I think connect-src should take care of this.

> I disagree. There are many valid use-cases where you'd want to preload dependencies, etc.

I am sorry, I was under impression that Firefox supports preload. Apparently it does not yet.
I started looking at this as a way to speed up loading my second resource by introducing preload in the first resource loaded by a document that I don't have control over. However, I think potential security issues overweight performance improvements. 

> Attacker is the one compromising the third-party and inserting HTTP headers. While integrity metadata can ensure that the response body is what expected for certain MIME types, there is no existing control over unexpected headers, especially those that can trigger requests on embedder's behalf.

What kind of data can the attacker infiltrate in that scenario that it can't send directly to any third party? Do you have an example of an actual data leakage?

> I am not sure about this. Preload requests are not governed by CSP at all (both in the spec and the Chromium implementation), no matter who the carrier is. @mkwst, WDYT? I think connect-src should take care of this.

A note from the preload spec (actual processing is defined in Fetch):
"The fetch initiated by a preload link is subject to relevant CSP policies determined by the value of the as attribute - e.g. when set to image the fetch is subject to image-src. Similarly, the value of the as attribute is used to initialize request headers and priority. If the as attribute is omitted, the request will be initialized with similar processing and request properties as one initiated by XMLHttpRequest."

If you see a case where Chrome's implementation doesn't match that, please file an issue.

shekyan@ - any concrete examples of data leakage here?

No concrete examples, no. The only concrete thing on my mind is that if it is possible to control response headers of a party resource, it becomes an attack vector on the embedder document. SRI would miss that.
Still can be mitigated by a CSP policy that would cover all possible resource types, which is rare.

Lacking concrete data leakage examples, marking as WONTFIX.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot