User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

Go to my.ccc.edu or http://my.ccc.edu.

Actual results:

Since the latest FireFox update, the application errors out and redirects to https://logon.ccc.edu/adfs/ls/?wa=wsignout1.0.

Expected results:

http://my.ccc.edu should redirect to: https://cccihprd.ccc.edu/psp/cccihprd/EMPLOYEE/EMPL/h/?tab=Z_CCC_GUEST.

This is working fine in other browsers, MS Edge, Chrome and Safari, and was also working fine in an old version, 57.0.1 (64-bit).

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

MozRegression points to:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9505197158716faadc101286218960166e038c6f&tochange=9a55ce1e0df8375be5c3f24a25c051067bf1bfa5

This bug goes away if I set network.cookie.sameSite.schemeful to false. This pref was enabled in bug 1750972 and shipped to release in Firefox 104.

Set release status flags based on info from the regressing bug 1744945

Tom, Freddy, can you take a look please? Seems like a regression we should fix.

FWIW, I can reproduce this and see the console log below:

Cookie “PS_TOKEN” with the “SameSite” attribute value “Lax” or “Strict” was omitted because of a cross-site redirect. h
Cookie “ps_theme” with the “SameSite” attribute value “Lax” or “Strict” was omitted because of a cross-site redirect. h
Cookie “PS_DEVICEFEATURES” with the “SameSite” attribute value “Lax” or “Strict” was omitted because of a cross-site redirect.

Note that if I open the same page in private window, this issue is gone.

I don't know really what is going on. Looks like some page sets explicit SameSite=Strict cookies using document.cookie.

document.cookie = "ps_theme=node:EMPL portal:EMPLOYEE theme_id:Z_GUEST_THEME css:Z_BRAND_CLASSIC_TEMPLTE_FLUID css_f:Z_BRAND_FLUID_TEMPLATE_858 accessibility:N macroset:Z_SS_MACROSET_856 formfactor:3 piamode:2 ; path=/; domain=.ccc.edu;" + ((window.location.protocol == "https:") ? " secure;" : "") + ("; SameSite = Strict");document.cookie = "HPTabName=Z_CCC_GUEST; path=/; domain=.ccc.edu;" + ((window.location.protocol == "https:") ? " secure;" : "") + ("; SameSite = Strict");document.cookie = "HPTabNameRemote=; path=/; domain=.ccc.edu;" + ((window.location.protocol == "https:") ? " secure;" : "") + ("; SameSite = Strict");document.cookie = "LastActiveTab=Z_CCC_GUEST; path=/; domain=.ccc.edu;" + ((window.location.protocol == "https:") ? " secure;" : "") + ("; SameSite = Strict");

But it does do a redirect from http:// to htps:// so I guess the domains aren't schemefully equal.

Note that if I open the same page in private window, this issue is gone.

This probably happens because we have HTTPS only mode enabled by default in private browsing mode, so the http to https redirect happens internally.

The page also uses the Set-Cookie header to set cookies. First I suspected that the space in some of the Samesite =Strict; key/value pairs might cause some kind of different behavior in Chrome and Firefox, but both seem to ignore it.

We have no plans to enable schemeful-samesite on the ESR branch. For releases, bug 1750972 (fx104) is a more relevant regressor.

This change was shipped in Firefox 104 in August, but this bug was noticed by the reporter "since the latest update" to 106. Do we need to worry something else is going on, or just assume that the reporter doesn't update very often? Valentine's nightly mozregression in comment 2 seems pretty definitive.

The redirects and cookie setting seems to be the same on Edge. The initial insecure request simply redirects to secure and sets no cookies. It redirects a whole bunch more times and Strict cookies are set during those redirects, and used in later redirects. In Firefox we're looking at the whole request-chain and saying "this redirected across schemes", and chromium appears to be saying "these redirects stayed secure since this cookie was created" or something like that.

(In reply to Daniel Veditz [:dveditz] from comment #8)

We have no plans to enable schemeful-samesite on the ESR branch. For releases, bug 1750972 (fx104) is a more relevant regressor.

This change was shipped in Firefox 104 in August, but this bug was noticed by the reporter "since the latest update" to 106. Do we need to worry something else is going on, or just assume that the reporter doesn't update very often? Valentine's nightly mozregression in comment 2 seems pretty definitive.

Hi Daniel,

I'm the reporter and yes, I didn't update FireFox very often until now. In the past, any changes, including FireFox, had to be pushed out by the administrators. However, I don't think that is the case with the students who are the main users of this website and we didn't get such ticket until recently.

Please help me understand, Dan. Does this mean that we implement "schemeful samesite" different (or maybe even incorrectly) from Chromium?

We definitely implemented it differently. After re-reading the specs I think Chrome is correct (not surprising given Chrome folks basically wrote this section). I was correct in thinking this was defined as a non-same-site request because of the redirects, but there's a note saying that top-level navigations can always set cookies even if the browser wouldn't send the cookies back because it's not same site.

https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-10.html#section-5.5-3.18.2.3.2

Note: Top-level navigations can create a cookie with any SameSite value, even if the new cookie wouldn't have been sent along with the request had it already existed prior to the navigation.

This difference could affect other sites using SameSite cookies, not just the "schemeful" sort. The fact that we haven't seen this in other web compat issues is a good sign, though.

Hi, it sounds that there is something FireFox rolled out that is causing the issue. Can you please suggest a workaround that can be implemented on our end to overcome this?

Note: Top-level navigations can create a cookie with any SameSite value, even if the new cookie wouldn't have been sent along with the request had it already existed prior to the navigation

I think that means we should not set isForeignAndNotAddon for top level documents.

Hi, it sounds that there is something FireFox rolled out that is causing the issue. Can you please suggest a workaround that can be implemented on our end to overcome this?

This change has been in Firefox since a while. You should look into redirecting less. Maybe setting up HSTS would also work around this issue after a reload.

(In reply to Tom Schuster (MoCo) from comment #15)

I think that means we should not set isForeignAndNotAddon for top level documents.

Yes, that looks right. We also have to make the equivalent change in CookieServiceChild.cpp

This code has been like this since 2020 or so which means we may want to update ESR as well. The my.ccc.edu site triggered the bug because of a SchemefulSameSite redirection which was only recently enabled, but the underlying flaw would affect any kind of SameSite cookie. Maybe we just got lucky? or maybe cross-origin top-level navigation redirects that set cookies was mostly used for "Bounce Tracking", and that kind of cookie was already blocked by Tracking Protection?

The fix you described should be small and safe enough that we could get approval to uplift in early beta. I'm going to optimistically put this on the Fx109 radar.

The bug is marked as tracked for firefox109 (beta) and tracked for firefox110 (nightly). However, the bug still isn't assigned and has low severity.

:freddy, could you please find an assignee and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Moving over to necko triage

This is a reminder regarding comment #17!

The bug is marked as tracked for firefox109 (beta) and tracked for firefox110 (nightly). We have limited time to fix this, the soft freeze is in 14 days. However, the bug still isn't assigned.

This is a reminder regarding comment #17!

The bug is marked as tracked for firefox109 (beta) and tracked for firefox110 (nightly). We have limited time to fix this, the soft freeze is in 13 days. However, the bug still isn't assigned.

This is a reminder regarding comment #17!

The bug is marked as tracked for firefox109 (beta) and tracked for firefox110 (nightly). We have limited time to fix this, the soft freeze is in 10 days. However, the bug still isn't assigned.

This is a reminder regarding comment #17!

The bug is marked as tracked for firefox109 (beta) and tracked for firefox110 (nightly). We have limited time to fix this, the soft freeze is in 9 days. However, the bug still isn't assigned.

Necko is going to take a look at this soon.

RC week is next week. We're going to have to target a fix for next cycle at this point.

This is a reminder regarding comment #17!

The bug is marked as tracked for firefox110 (nightly). We have limited time to fix this, the soft freeze is in 8 days. However, the bug still isn't assigned.

(In reply to Daniel Veditz [:dveditz] Out until Jan 9 from comment #16)

(In reply to Tom Schuster (MoCo) from comment #15)

I think that means we should not set isForeignAndNotAddon for top level documents.

Yes, that looks right. We also have to make the equivalent change in CookieServiceChild.cpp

Unfortunately, not setting isForeignAndNotAddon for top level documents seems seems not a right approach for this bug. Or maybe that site has been changed recently?

I just tested this again before wiring this comment.
It looks like this issue is caused by the fist redirect from http://my.ccc.edu/ to https://my.ccc.edu/.
And then, firefox looks at the whole redirect history here and find out that the first redirect is not schemeful samesite.

I think the correct approach might be having the same implementation as chromium (as said in comment #9), but I am not sure if it's easy to change in a few days.

Valentin, Tom, what do you think?

This is a reminder regarding comment #17!

The bug is marked as tracked for firefox110 (nightly). We have limited time to fix this, the soft freeze is in 7 days. However, the bug still isn't assigned.

I am not convinced that Chrome's implementation actually works like comment #9 suggests. I can't really imagine a reasonable implementation for this, you would have to keep track of where in the redirect chain the cookie it was created and then only go back comparing from that point?
Who knows I guess...

We probably won't get away without actually reading Chrome's implementation at that point. I think cookie_util.cc would be a good starting point.

Well, I've looked into the behavior of Chrome and it turns out that Chrome's implementation is similar to Firefox.
They've implemented the redirect chain check in this issue and they also encountered some site breakages.
Then, they decided to put the redirect chain check behind this feature kCookieSameSiteConsidersRedirectChain, which is not enabled for now.

I've also verified this behavior with Chrome version 108.0.5359.124 by myself. My steps are:

1. Open http://my.ccc.edu/ with chrome.
2. The site is redirected to https://cccihprd.ccc.edu/psp/cccihprd/EMPLOYEE/EMPL/h/?tab=Z_CCC_GUEST.
3. Open chrome://flags/ and enable Experimental Web Platform features (kCookieSameSiteConsidersRedirectChain is overwriten here).
4. Relaunch Chrome and open http://my.ccc.edu/ again.
5. It ends up with the same page https://logon.ccc.edu/adfs/ls/?wa=wsignout1.0 as Firefox does.

Given that Chrome doesn't enable schemeful samesite check, I think we should also disable this feature (network.cookie.sameSite.schemeful).

What do you think?

Can you clarify: Do they not check the redirect chain at all or do they just not check the scheme? Omitting the scheme check seems a lot less dangerous to me.

(In reply to Tom Schuster (MoCo) from comment #30)

Can you clarify: Do they not check the redirect chain at all or do they just not check the scheme? Omitting the scheme check seems a lot less dangerous to me.

Looking at the code here, I think they do check the redirect chain, but allow the result to be overwritten by kCookieSameSiteConsidersRedirectChain.

Tom, should we disable network.cookie.sameSite.schemeful on release? Thanks

Yeah good idea, disabling network.cookie.sameSite.schemeful fixes the problem with the site.

(In reply to Tom Schuster (MoCo) from comment #33)

Yeah good idea, disabling network.cookie.sameSite.schemeful fixes the problem with the site.

Could you file a bug about it? Thanks

(In reply to Pascal Chevrel:pascalc from comment #34)

(In reply to Tom Schuster (MoCo) from comment #33)

Yeah good idea, disabling network.cookie.sameSite.schemeful fixes the problem with the site.

Could you file a bug about it? Thanks

I can create a patch in this bug.

https://hg.mozilla.org/mozilla-central/rev/87ee052115c4

Then we don't ship sameSite schemeful forever? Disabling sameSite schemeful is only a workaround, not a proper fix.

(In reply to Masatoshi Kimura [:emk] from comment #39)

Then we don't ship sameSite schemeful forever? Disabling sameSite schemeful is only a workaround, not a proper fix.

Not sure what is the proper fix for this bug. I think we implemented the redirect chain correctly. The problem is at the server side.
I think we either change the cookie spec to allow this or wait until Chrome enables the redirect chain check first.

Comment on attachment 9314177 [details]
Bug 1800273 - Disable network.cookie.sameSite.schemeful, r=freddyb

Beta/Release Uplift Approval Request

• User impact if declined: Some websites could not work.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: N/A
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low. This is a pref flip.
• String changes made/needed: N/A
• Is Android affected?: Yes

https://hg.mozilla.org/releases/mozilla-beta/rev/b79e2e98e5f1

Reproduced the issue on Firefox 106.0 under macOS 11.7.3 by following the informations provided in Comment 0.

The issue is fixed on Firefox 111.0a1 (2023-01-29) and Firefox 110.0b7. Tests were performed on macOS 11.7.3, Windows 11 and Ubuntu 22.04.

ESR102 is not affected as the pref was set to false on release for 102:
https://searchfox.org/mozilla-esr102/source/modules/libpref/init/StaticPrefList.yaml#10034

Closing it as Verified Fixed in this case. Thanks!