Same-Site cookies and redirects

[mozfreddyb]

We noticed a difference between Firefox & Chrome’s behavior for same-site cookies. Specifically, if a web page is requesting a resource whose final redirect target is same-site with the web page, Chrome will treat it as same-site (crbug 1221316). Firefox follows what was originally decided in https://github.com/httpwg/http-extensions/pull/1348 and specified in recent drafts of rfc6265bis i.e., Firefox looks at the whole redirect chain.

For context: Firefox shipped SameSite=Lax by default this January and had to backpedal due to this (and some other webcompat issues). Firefox does not ship SameSite=Lax as the default setting for new cookies as of now. While we’re still working on our own metrics, we’ve noticed that Chrome is seeing about 1% of page loads potentially affected, which seems prohibitively high. At the same time, we would prefer not to weaken our implementation of explicit SameSite cookies, given that the redirect check was specifically added to prevent CSRF abuse scenarios.

With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie.

@miketaylr, @sbingler: it would be nice to hear some thoughts about this idea and also @johnwilander how other browsers may have implemented #1348.

CC: @miketaylr, @sbingler, @dveditz, @annevk, @evilpie, @johnwilander

[miketaylr]

While we’re still working on our own metrics, we’ve noticed that Chrome is seeing about 1% of page loads potentially affected, which seems prohibitively high. At the same time, we would prefer not to weaken our implementation of explicit SameSite cookies, given that the redirect check was specifically added to prevent CSRF abuse scenarios.

Yeah, I agree this is unfortunate. We did attempt to ship this behavior, but it broke a few sites and was backed out (or rather, put behind an off-by-default feature flag). @sbingler has been collecting better metrics so we can hopefully make progress on this.

With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie.

Can you give some more detail what you're thinking here?

(also cc @mikewest)

[evilpie]

With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie.

Can you give some more detail what you're thinking here?

Firefox is already enforcing that all redirects are same-site for cookies that have an explicit SameSite=lax or strict attribute. We would like to keep that restriction of course. From my understanding the idea would be that only cookies that don't define their own SameSite attribute and are then "lax-by-default" we would ignore the redirects.

[dveditz]

As a side note, Chrome does send Sec-Fetch-Site: cross-site with these redirected sub-resource requests, so internally the networking code does seem to know the correct same-site value of the request.

Obviously we'd like to do the more secure behavior all the time, but we are committed to doing the specified secure behavior for explicit SameSite cookies. Firefox has enforced this for explicit SameSite cookies for maybe around a year and has not suffered a noticeable amount of web incompatibility. We are in the (slow!) process of gathering telemetry to measure the impact of this on laxByDefault vs explictly SameSite cookies.

Our hope is that we can convince Chrome folks to honor the spec for explicit SameSite cookies so that users and sites will be secure as promised by the spec, and that Firefox will be less likely to run into Web Compatibility problems in the future because of this. And that if we must weaken the behavior of laxByDefault (as it appears we must based on site breakage) that we explicitly change the spec to say "lax-ish by default" cookies follow Chrome's current behavior of ignoring redirects and comparing only the originator and the final request URL.

[sbingler]

Hello and sorry for my late response.

Our (Chrome's) metrics continue to show around 1% of page loads containing 1 or more cookies that would be blocked by this enforcement. While I'm unable to share numbers (yet, I'll add them to https://crbug.com/1221316 once they're approved) I can say that the vast majority of SameSite values triggering this are unspecified (lax by default).

I wonder then if many of these cookies are likely those being accessed after a POST request from some login or payment flow redirect chain. I don't have any data to back this hunch up but https://crbug.com/990439#c13 hints this may be the case.

If it is then perhaps we can tie the redirect chain enforcement to the 2 min Lax+POST mitigation. I.e.: Allow unspecified cookies to be accessible after cross-site redirects for up to 2 minutes. While I worry this will further ossify that "temporary" mitigation it feels better than a blanket except for unspecified cookies. Given our metrics I don't think your proposal is unreasonable, but the more we can tighten the restriction the better.

Any thoughts? Does Firefox have any data that could support or refute my idea?

(Tangentially: I'd still like to see the 2 min exception removed, but I get a headache even thinking about it.)

[miketaylr]

tagging @dveditz @mozfreddyb for visibility to the above comment.

I think tying this to the 2 minute exception is fairly reasonable - 1% of page loads is sadly much too high to ship what the spec describes in any reasonable time frame. Perhaps some pages would still break, but it's worth a shot.

And I agree we should change the spec to match (whatever becomes) reality here.

[annevk]

What about the idea of differentiating between explicit SameSite=Lax and Lax-defaulted SameSite? Not ideal, but then at least there won't be a security regression for those who opt into SameSite=Lax.

Then for Lax-defaulted SameSite we could do something along the lines you propose, in name of webcompat.

[sbingler]

Right, we already differentiate between explicitly Lax (Set-Cookie: a=b; SameSite=Lax) and unspecified (Set-Cookie: a=b) when it comes to the 2 min Lax+POST mitigation. Only the unspecified cookies qualify for that mitigation, explicitly Lax do not. (Perhaps it would have been better to name it Unspecified+POST, oh well)

I'm suggesting to continue that pattern for the redirect chain exception, so I think we're in agreement.

[mozfreddyb]

@sbingler Yes, that's aligned with our thinking right now. Do you have numbers that can help us gain more clarity for these exact cases (a redirect where the final URL is same-site, but the overall chain is to be considered cross-site, also called "boomerang redirect") and split up into explicit-lax and default-lax?

We're still in the process of collecting those within Firefox, but are obviously interested in your insights so far.

[sbingler]

@mozfreddyb

I think https://crbug.com/1221316#c16 has what you want. Those numbers are from roughly a week ago.

tl;dr Between 80-90% of cookies are unspecified/default lax. Cookies that are being newly written are on the higher end of the range, cookies being read are lower.

[johnwilander]

Hi! John from Apple WebKit here.

If we standardize different behavior for default vs explicit SameSite=lax …

1. We increase the complexity of SameSite cookies significantly. Is that desirable?
2. Will developers be able to know the difference without this effectively being displayed as an additional cookie attribute in developer tools?
3. Are we arriving at the desired end state or piling on more legacy and technical debt?

It looks to me like this should instead be a fourth SameSite value, beside none, lax, and strict. Then we’ll have to decide if the new, fourth value is the default or the old explicit lax.

I generally don’t like fixing legacy problems by increased spec complexity since it doesn’t help the web/Internet progress.

I will bring this up with the CFNetwork folks at Apple to see what they have to say.

[sbingler]

Hi John,

You bring up some good points. I'm curious if the CFNetwork folks had anything to add.

[annevk]

I think what's under discussion is making the fourth value explicit in the specification. It apparently is already a thing in some implementations. I'm not sure we have a good reason to expose it in syntax though. But yeah, a clear name in the specification would help with tooling and such.

[miketaylr]

I'm not sure we have a good reason to expose it in syntax though.

+1

[dveditz]

"Default" is an explicit value for the same-site-flag in the algorithms and storage model defined in Section 5. It's not a part of the Set-Cookie: syntax.

Unfortunately it looks like the § 5.5 Storage Model algorithm only sets the same-site-flag if there's an explicit SameSite attribute in step 17 ("Default" is used for an otherwise unknown value). Presumably the same-site-flag should be initialized to "Default" somewhere, but that's an assumption and not explicit. The value of same-site-flag is technically undefined if there isn't a SameSite attribute and that's clearly not the intent.

[zhenchaoli]

Hi, Zhenchao Li from Apple working on CFNetwork.

This change sounds quite complex to me. Although, if it means minimizing website breakage and tightening cookie restriction, I'm in favor of explicitly adding the behavior to the RFC.

It does sound like we need to move from "SameSite=lax by default" to "SameSite=[fourth value] by default". Also, "default" still needs to be a separate state persisted in "Storage Model" so as not to be conflated any time. (I believe this is intended by latest draft, but as @dveditz pointed this might need some changes to the Storage Model section)

@sbingler

• Could you help clarify more about "2 min Lax+POST mitigation"? I see it mentioned above but it would be great to discuss how the mitigation should behave exactly.

[sbingler]

Could you help clarify more about "2 min Lax+POST mitigation"?

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.4.7.2 is the spec language around the behavior. As a quick refresher: the goal is to allow unsafe http methods (commonly POST) to attach cookies that do not specify a SameSite attribute but are being treat as "lax by default". This behavior is intended for newly created cookies and so has a lifetime limit of up to 2 minutes.

Let me know if you have any more specific questions.

[johannhof]

We (@miketaylr, @annevk, @sbingler and I) discussed this at TPAC and came to the following suggestion:

1. We think that browsers have to apply a compatibility measure here, and it could be including cookies on cross-site redirects if they’re younger than, for example, 2 minutes.
2. We’ll collect metrics to get a better understanding of what that number should be.
3. We will update "Lax-Allowing-Unsafe" in the spec to document that behavior, which would make Chromium compliant to that and Firefox could (AFAIU) ship a compliant version as well.
4. We’ll continue to recommend "Lax-Allowing-Unsafe" as the default behavior in the spec. We’ll note that this is a compatibility mechanism that browsers may support or not support at their own discretion. It's not a behavior sites should opt into.

[sbingler]

I believe the "same-site redirect chain consideration" change should be removed from RFC6265bis, with the intention of adding it back to RFC6265Tris.

RFC6265bis contains a number of improvements over RFC6265 that are being stalled due to UAs being unable to implement "same-site redirect chain consideration" in a web compatible way. My efforts examining metrics collected by Chrome haven't yet offered much insight into how this issue could be solved and I have no idea how much longer it could take.

Because no UAs (to my knowledge) have shipped "same-site redirect chain consideration" I don't believe reverting the language will have any practical effect and shouldn't weaken any active protections. But publishing RFC6265bis as a new spec will have a number of benefits, including security/privacy benefits for the web's users.

[johannhof]

This seems like a reasonable, pragmatic step to me. The current limbo state isn't helping anyone :)

cc @annevk

[miketaylr]

My efforts examining metrics collected by Chrome haven't offered much insight into how this issue could be solved and I have no idea how much longer it could take.

Because no UAs (to my knowledge) have shipped "same-site redirect chain consideration" I don't believe reverting the language will have any practical effect and shouldn't weaken any active protections.

Yes, +1 to documenting reality and no longer blocking the IETF process for 6265bis on this particular item (which I do agree we should treat as a security bug to be eventually solved).