search

whatwg / fetch

Fetch Standard
https://fetch.spec.whatwg.org/
Other
2.11k stars 330 forks source link

Request needs to propagate concept of "main frame navigation" #1327

Open wanderview opened 3 years ago

wanderview commented 3 years ago

As discussed in #1321 we want to propagate the internal origin field when a Request constructor copies another request without modifying it. One of the reasons for this is so that SameSite cookies will work properly when there is a pass-through service worker handler.

Unfortunately, during the discussion at the F2F call (w3c/ServiceWorker#1604) I forgot to mention another problem. SameSite cookie computation currently depends on if the request is for a top-level main frame navigation:

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-05#section-5.3.7.1

This is used to expose SameSite=LAX cookies on these main frame navigations. In addition, I believe at least chrome defaults cookies to SameSite=LAX if there is no SameSite attribute.

This means that if we want to propagate the origin we probably need to propagate some "main frame navigation" bit as well. Otherwise sites may suddenly start losing cookies on cross-site navigations when they add a service worker.

Ideally we would just propagate the request destination to achieve this. Unfortunately, this also has difficulties as discussed in #1323; e.g. changing the destination would change CSP enforcement behavior.

So that leaves us with an internal "main frame flag" or an internal "original destination" field. What do folks think? @annevk, @arturjanc, @jakearchibald, @asutherland, @youennf

annevk commented 3 years ago

I don't see how destination or "is this top-level" (which I guess is what you mean with main??) helps with the cross-site determination that is needed.

I think what you need is @arturjanc's https://github.com/w3c/webappsec-fetch-metadata/issues/56#issuecomment-601283642, right? cc @davidben

wanderview commented 3 years ago

I'm not sure I follow. A single "top-level frame" bit seems to be adequate to satisfy this:

"In the interests of providing a drop-in mechanism that mitigates the risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a "safe" (in the [RFC7231] sense) HTTP method."

I think the ancestor frame information is captured in "site for cookies"?

annevk commented 3 years ago

Ah, I had missed that. How is "site for cookies" conveyed to the server though?

wanderview commented 3 years ago

Well, "site for cookies" itself is not conveyed to the server. It simply takes part in determining if SameSite=Strict cookies, etc, are sent to the server.

I do think, though, that if we had Sec-Fetch-Ancestors we could use that information for this as well. (If its propagated through the fetch in a service worker.) And of course since destination distinguishes between document and iframe it has the information as well, but it isn't propagated through the SW.