SameSite cookies: Cross-site top-level navigation followed by redirect back to the first party

[chlily1]

(Notation: => is a navigation, -> is a redirect, "A" is the first party site which has SameSite cookies set on it.)

Currently, top-level A=>B->A results in sending both Strict and Lax cookies on the redirect back to A, as reflected in this WPT testcase: https://github.com/web-platform-tests/wpt/blob/master/cookies/samesite/form-get-blank.html#L58

This should ideally send Lax (but not Strict) cookies, because the analogous top-level navigation scenario A=>B=>A would result in sending only Lax but not Strict cookies to A on the last navigation.

[kiding]

I'd like to weigh in on resolving this issue since the browser implementations have diverged.

Following the A=>B->A example, the Chrome/Chromium test cases (implemented by @chlily1, exported to web-platform-tests) assume both A's are "strictly same-site." (See wpt@2379191)

On the Safari/WebKit side, the test cases assume both A's are not strict. (See webkit@d615092) This behavior (which I personally prefer) is consistent with the A=>B=>A scenario. Firefox/Gecko behaves like WebKit. (See gecko-dev@15cc802) There even is a 2-year-old bug 1456408 that's basically the same as this issue.

FYI, A simple demo page to test with is available at https://brass-tremendous-marmoset.glitch.me.

[englehardt]

There are actually three conditions for which we'd want to consider these types of redirects:

1. User types B.com into the address bar which redirects to A.com. (request's client is null, so visit to A.com is considered strictly same-site)
2. User clicks a link on A.com navigating to B.com which then redirects back to A.com. (request's initiator is A.com, so final visit to A.com is considered strictly same-site)
3. User visits A.com. A.com embeds a resource from B.com, which then redirects to A.com. (request's origin is strictly same-site to top-level origin)

In all of these cases the redirect from B.com is attacker controlled, and thus the request to A.com should not be considered strictly same-site. I filed #1348 to remedy this in the spec. This roughly aligns with Firefox's implementation, though I'll note that we have a bug for embedded iframes where document.cookie will have access to same-site=strict cookies when the request for the embedded iframe is considered cross-site due to a cross-site redirect.

If we can align on this, I'm happy to flip the expected values in the various wpts that currently expect same-site=strict access after cross-site redirects. e.g., the two tests that Firefox fails here: https://wpt.fyi/results/cookies/samesite/img.https.html?run_id=5692294122438656&run_id=5715442855313408&run_id=5742652110667776&run_id=5740336754196480.

cc/ @chlily1 @miketaylr

[chlily1]

Closing since PR landed