Default SamSite cookie attribute isn't set to LAX in Mac
Categories
(Core :: Networking: Cookies, task)
Tracking
()
People
(Reporter: mohammadowais616, Unassigned)
Details
(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?])
Cookies aren't treated as SameSite=Lax in FF on Mac OS can lead to CSRF issues in web apps.
|
Reporter | |
Comment 1•5 years ago
•
|
||
Hi!
The default setting for SameSite cookie attribute is that they are set to LAX if they aren't manually set. This has been implemented by all browsers and FF also claims to have to implemented:
https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/#:~:text=When%20not%20specified,%20cookies%20will%20be%20treated%20as%20SameSite=Lax%20by%20default
I noticed this isn't true for FF on Mac.
- Set-up a web app that don't have SameSite attribute set on Cookies.
You can use this site to test this:
<edit: removed>
- Now open Firefox on Mac and make a GET request from a third party origin.
You can use this example:
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="/edit:removed">
<input type="submit" value="Submit request" />
</form>
</body>
</html>
- Notice that even those cookies are sent which do not have SameSite attribute set.
I tested the same from other browsers, seems like other browsers don't send them.
I believe this needs a fix.
Impact
As the new default mitigated CSRF, this won't mitigate them on web apps for Mac users.
Kind and Best Regards,
-MO
|
|
Reporter | |
Comment 2•5 years ago
|
||
Additionally, the cookies will be sent (if samesite atttribute isn't set) in both request types, GET and POSTs.
|
||
Comment 3•5 years ago
|
||
(In reply to Mohammad Owais from comment #1)
This has been implemented by all browsers and FF also claims to have to implemented:
https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/#:~:text=When%20not%20specified,%20cookies%20will%20be%20treated%20as%20SameSite=Lax%20by%20default
You're quoting this out of context - it's describing how things work when SameSite=lax by default is turned on, which it isn't in release channels. This is repeatedly explained in the blogpost ("At Mozilla, we are slowly introducing this change. And we are strongly encouraging all web developers to test their sites with the new default.", "Starting with Firefox 79 (June 2020), we rolled it out to 50% of the Firefox Beta user base. We want to monitor the scope of any potential breakage.", "There is currently no timeline to ship this feature to the release channel of Firefox.").
bug 1617609 (not sec-sensitive) tracks enabling this by default for release users. You can test that this works correctly using nightly, or setting the prefs outlined in the very article you linked...
Cookies aren't treated as SameSite=Lax in FF on Mac OS can lead to CSRF issues in web apps.
If the web app relies on SameSite attributes for security, then it should set that attribute, rather than assume the browser will do it for them. It would also be wise to add other protections for users that are on browsers that don't support SameSite cookies at all.
I'd clear the security flag but the link in comment #1 seems like a production site, so I guess it's better to keep this hidden until their site is fixed - I assume you've reported the issue to them, too?
|
|
Reporter | |
Comment 4•5 years ago
|
||
Thanks for sharing this information. Yes, I've reported the issue with them too and they are working on the fix. :)
If the web app relies on SameSite attributes for security, then it should set that attribute, rather than assume the browser will do it for them.
Is it also true when the FF makes changes in release channels too, or would it be worth to look into the security areas here?
|
||
Updated•5 years ago
|
|
||
Updated•2 years ago
|
Description
•