Early Hints's relationship to CSP

[annevk]

See w3c/preload#114.

It seems like Early Hints could potentially violate policies. Or perhaps 1xx responses need to be recommended to also include CSP policies?

[kazuho]

Would you mind elaborating on how it could violate a policy?

103 only allows speculative evaluation of the header fields, meaning that a client must not apply the header field found in the 103 response in a way that it affects how the final response is processed.

Considering that, I would argue that it would be a bug of a client if a header field of a 103 response causes a policy violation.

Or are you arguing about a case where that approach makes the header fields of 103 response unapplicable in practice?

[annevk]

Early Hints allows bypassing the policy stated in the final response. I think that's a problem of sorts.

[tunetheweb]

Is the concern than the early hint includes a different policy (or no policy at all)?

Or is the concern that a hint could include a resource that would be blocked by the final policy?

For the latter the resource could potentially be downloaded but then not be used if the ultimate policy blocks it. So this shouldn’t cause an XSS is ur but may cause a privacy issue and/or information leakage (e.g. a blocked image is downloaded when it shouldn’t be, or a resource is downloaded over insecure http despite the ultimate presence of upgrade-insecure-requests).

However since both the Early Hint and the CSP are served by the same server, and any attacker with access to change either has complete control, I’m not sure how much of a problem this really is?

[annevk]

Both are a concern. And in complex setups not all aspects of the server are administered by the same person, so this kind of mismatch can result in issues.

[annevk]

(It's not clear if an Early Hint can include a policy btw, that's not defined. Perhaps I should raise a new issue for that?)

[kazuho]

@annevk Thank you for your comments. Could you please check if my understanding (stated below) is correct?

When evaluating a link rel=preload header, the browser blocks the preload depending on the value of the "as" attribute. For example, loading of a image specified by the link header field is blocked, if the URL being contained is not allowed by the img-src property of the CSP header field.

By reading w3c/preload#37, I think that that is the expected behavior of preload.

Assuming that the above is correct, I agree with you that the specs should be interpreted that they ban fetching certain types of resources until the CSP value gets fixed in the final response. Such types includes images and fonts (the spec talks about blocking "loads"). OTOH, the rule does not apply to scripts or stylesheets, because CSP deals about "executing" or "applying" them.

Having said that, based on my understanding about CSP (stated above), I wonder preload referring to CSP has any value in terms of security (even though I think that it is a good optimization), because a server can always lie the value of the "as" attribute. For example, a server could send a link rel=preload header with as=style to initiate a load of a ".jpg" file, even in case CSP is set to "img-src=none".

To summarize, I would argue that the specs do not prevent us from fetching scripts or stylesheets designated by link rel=preload headers in a 103 response. I also argue that there is no need to block fetching other types of resources found in the 103 response.

[annevk]

CSP governs all fetches. So a policy that disables all cross-origin fetches could be circumvented if CSP is not applied.

[kazuho]

@annevk My read of https://www.w3.org/TR/CSP3/ is that CSP "controls the resources which a particular page can fetch or execute" (emphasis mine), and that scripts and stylesheets are allowed to be fetched, regardless of the value of the CSP header field.

Are you suggesting that I am interpreting the text incorrectly (it could be), or that browsers do not implement that way?

Or do you agree with the interpretation that scripts and stylesheets can be speculatively fetched regardless of the value of the CSP, but consider fetching other resources by observing the value of the link rel=preload headers without consulting CSP a security concern?

[annevk]

It controls both fetching and execution, but that doesn't mean it doesn't control the fetching of scripts (it does).

[kazuho]

@annevk Thank you for the answer. So CSP as a spec disallows fetching scripts or stylesheets.

Then, the issue seems to be in the hands of preload spec; I might suggest bypassing CSP rules when processing link rel=preload headers when processing a 103 response for the following reasons:

• CSP rules are applied when the browser sees a tag that loads the resources; link preloads can be considered a way to speculatively start fetching them
• considering the fact that the CSP header field and the link rel=preload header field are sent by the same entity, I do not think that there would be a security concern if the client starts fetching the resources designated by the link header prior tor receiving the CSP settings.

[annevk]

To quibble, CSP rules are applied whenever the browser fetches something in the context of a web page. I'd argue that includes 103, especially when we get origin-wide CSP policies.

It's a security concern in that a server operator now needs to be aware that CSP can be circumvented. So they would need to monitor all 103 responses somehow.

[mnot]

Anne, if a 103 response had both a preload Link header and a Content-Security-Policy header, would you think that workable?

[annevk]

Yeah, the problem still remains that server operators have to be aware of it. If one team deploys 103 without telling the security team, ... Anyway, that's what I suggested in OP and I still think that'd be acceptable.

Origin Manifest/Policy would make this less of a problem, but that doesn't seem to be happening anytime soon.