Closed Bug 1749634 Opened 2 years ago Closed 2 years ago

Firefox no more send cookies on v96 because of new Cookie politics with http/https

Categories

(Core :: DOM: Security, enhancement)

Firefox 96
enhancement

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: piradix, Unassigned)

References

Details

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

Steps to reproduce:

Get json data from web service (local) from a session in developer mode

Actual results:

I get empty data because Firefox no longer sends the session cookie.
Everything was fine on Firefox 95.
As of today, my whole development environment is broken, because of the new Firefox 96 policy on "SameSite = Lax" and https cookies.
Is it possible to disable this check on a development environment?
For information, a development environment is often:

  • use localhost / 127.0.0.1
  • no ssl: http
  • if ssl, the certificate is not valid because of localhost!
  • it's Firefox for developer ;-)

Expected results:

When :
-1) I connect to "http: //localhost/login.htm", which sends a session cookie with a page of my application
-2) I connect to "http: // localhost: 9000 / index.html" (an Aurelia-js framework application of the vuejs or angular type). From this page, I would like to receive my username that I usually get with a code like:
http.fetch ("http: // localhost / user / name", {method: 'GET', credentials: "include"})
Before with Firefox 95 the "fetch" sent the session cookie and retrieved the data.
With Firefox 96 it no longer sends the cookie, so my data is empty!

The problem is due to the new cookie policy ("SameSite = Lax" and HTTPS).
In production, I understand this is a good choice. But in dev mode, Firefox became unusable.
For information, chrome has a mode to deactivate it.

What can I do ?
I have 6 projects currently blocked by Firefox 96!

In "localhost" mode, I consider this kind of policy as a bug, a nonsense, in particular on "Firefox for developer"

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

Component: Untriaged → Security: PSM
Product: Firefox → Core
Component: Security: PSM → DOM: Security

Adding a developer mode (on Firefox for developer) with less security on localhost will help all developers.

Currently, to test a web page calling a service on the same development machine (typical case), you must install an SSL certificate on the web service and configure the latter with a "sameTime = lax". Creating a certificate locally is not easy and prevents some debugging tools from working. In addition, the next security policy will surely be to prohibit connections with invalid certificates (self-signed).

So a way to disable this kind of security for developers in develop mode seems to me to be a good compromise:

  • security is preserved
  • developer mode (one button) limits this lack of security and simplifies our lives.
  • Chrome already has a way to disable some of the security. This feature gives Chrome a head start for web development
Blocks: sameSiteLax-breakage
No longer blocks: samesitelax

Does network.cookie.sameSite.laxByDefault.disabledHosts help?

Set network.cookie.sameSite.laxByDefault.disabledHosts to true don't work.
And set a variable like "network.cookie.sameSite.laxByDefault.disabledHosts" is not a good solution because you break all Firefox security on internet for all web sites.

But a good solution to disable the cookie protection (SameSite=none pby default) will be to set "SameSite=lax" when a user disable the shell "reinforced protection" (Protection renforcé) of Firefox.
Then you simplify the work of :

  • developer on localhost
  • devOP work.

For information : the new politic of default "SameSite=none" and use "HTTPS", break tools chain of developer:
To workaround this problem, a developer must :

  • set a cookie policy on it localchost server (not always possible in particular test server is not on localhost)
  • configure a https service (not always possible, but a revers proxy (like stunnel) can help)

In my case, I lost 2 days to find a workaround for 1 project for me. Now I must set my solutions on every project and on all developer environment : super !

(In reply to Piradix from comment #5)

Set network.cookie.sameSite.laxByDefault.disabledHosts to true don't work.
And set a variable like "network.cookie.sameSite.laxByDefault.disabledHosts" is not a good solution because you break all Firefox security on internet for all web sites.

network.cookie.sameSite.laxByDefault.disabledHosts is not a boolean pref. The value is comma-separated host names that you want to revert the behavior. That is, localhost for your case.

thank's(In reply to Masatoshi Kimura [:emk] from comment #6)

(In reply to Piradix from comment #5)

Set network.cookie.sameSite.laxByDefault.disabledHosts to true don't work.
And set a variable like "network.cookie.sameSite.laxByDefault.disabledHosts" is not a good solution because you break all Firefox security on internet for all web sites.

network.cookie.sameSite.laxByDefault.disabledHosts is not a boolean pref. The value is comma-separated host names that you want to revert the behavior. That is, localhost for your case.

Thank's, it work ;-)
put "localhost" in "network.cookie.sameSite.laxByDefault.disabledHosts" disable the cookie samesite politic with https.
I hope Firefox will never remove this solution.

It is not complicated to apply. The only problem is that there is no native Firefox interface to enable it. Because there is a lack of user-friendly documentation on this subject....

Firefox, if you think you are doing something, I can help you with the concept, proofread the doc, translate it (in French) ...

Ultimately there are three prefs which all would need to be flipped to false to disable samesite=lax cookies:

  • network.cookie.sameSite.laxByDefault
  • network.cookie.sameSite.noneRequiresSecure
  • network.cookie.sameSite.schemeful

Further, there is documentation on MDN about samesite cookies which might be helpful:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.