SameSite=None Secure=false cookies are still sent in cross origins and insecure communications after changing network.cookie.sameSite.noneRequiresSecure
Categories
(Core :: Networking: Cookies, defect, P2)
Tracking
()
People
(Reporter: test53777, Assigned: edgul)
Details
(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?][necko-triaged][necko-priority-next])
Attachments
(3 files, 1 obsolete file)
The cookie that should be rejected is indeed stored.png
In the Mozilla Firefox Browser documentation regarding to cookies SameSite attribute (https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies), it specifies the following:
"Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context)."
I am being able to define (in Mozilla 124.0.2 64-bit) not only client side cookies, but also returning the Set-Cookie header from my server with a specific notation, that bypasses security controls, and allows cookies with SameSite=None, to be defined without the Security attribute. This allows sensitive cookies to be sent in non-secure connections. Furthermore, if a server returns the Set-Cookie header with a cookie that has a value with the vulnerable form, the cookie will be stored as SameSite=None and Secure = False.
Steps To Reproduce:
1- Set a cookie in javascript for example in the domain http://example.com . Go to the Console, and type the following: document.cookie = "hackerOne=test; SameSite=None" (You will se a warning that the cookie was rejected, but the cookie is still stored).
2- Go to "Storage" and see that the cookie is stored as SameSite=None, and Secure=False.
3- Now go to another site, lets say http://httpforever.com/, and add the following form by manually editing the HTML in the console Editor:
<html>
<body>
<form action="http://example.com/" method="POST">
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
Then press the "Submit" button in the page. You will see that the cookie is sent in a Cross-Origin POST (confirming SameSite=None), and is sent over an insecure connection (confirming Secure=False).
5- Repeat the process, but instead of defining the cookie by javascript, in step 1 when you make the first get to http://example.com, intercept the response and add the Set-Cookie: hackerOne=test;SameSite=None.
You will see the same warning as seen in step 1, but the cookie is set. By repeating step 4, you will see that the cookie is also sent.
In the evidences, I show how setting the vulnerable cookie, despite giving the Warning message does not evict the cookie, and allows it to be sent in a X-Site POST, and over an HTTP Connection.
(This is a browser issue).
|
||
Comment 3•1 year ago
|
||
That page pretty clearly says
Note: The standard related to SameSite recently changed (MDN documents the new behavior above). See the cookies Browser compatibility table for information about how the attribute is handled in specific browser versions
which then says:
From version 69: this feature is behind the network.cookie.sameSite.noneRequiresSecure preference (needs to be set to true). To change preferences in Firefox, visit about:config.
wrt the "Secure" requirement. This is still the case. As a result, I don't think this bug is valid.
Furthermore, if a server returns the Set-Cookie header with a cookie that has a value with the vulnerable form, the cookie will be stored as SameSite=None and Secure = False.
That server is doing something that's not ideal, but that isn't ultimately a security bug in the browser - we've tried pretty hard to restrict insecure use of cookies on the browser side (in various ways, of which this is just one) and keep hitting browser compatibility issues (e.g. deps of bug 1651119), which have stopped us rolling some of these features out more widely.
I'll leave Greg and Ed to decide whether to close this bug out and/or if there's somewhere it can be duped.
You are right. I had the sameSite.noneRequiresSecure disabled. Anyway, investigating a little bit more, If I previously had the flag disabled, and I have cookies that have already been set as SameSite=None and Secure=False, I believe this cookies should be evicted, or at least the browser should not send them as the config has changed. Isnt that right? I just tested this scenario, and cookies that were previously defined as SameSite=None and Secure=False, keep being sent in cross site and insecure communications.
the browser should not send them as the config has changed
This seems like something that we could do. Passing to valentin for comment.
Great. Just let me know if there's something I can do on my side!
This pref is enabled on nightly and early beta meaning in the middle of the beta cycle it changes values, so this isn't actually an isolated change.
I think it it makes sense to check the pref when deciding whether to send those cookies or not.
Great! Thank you both.
Please let me know when we can set the severity for this issue, so I know if it is elegible for bounty or not.
The worst case scenario I can think of, is a server that return Set-Cookie: JSESSIONID=x;SameSite=None; and later the user changes his preferences to network.cookie.sameSite.noneRequiresSecure = true. A malicious user that is in the same network than the victim, only has to provide the victim with an http link of the page that previously setted the cookie, or see if the page has any http link. In this cases, the only requirement is that the malicious actor can sniff the network traffic of the victim. Unless the server changes adds the Secure flag to new cookies, this attack will always be possible.
|
||
Updated•1 year ago
|
Thanks guys. I see this bug is triaged. Do you have any references so I can see how the process continues? I understand that if its triaged as P2 it should be appliable for bounty, but I wait for your response.
Let me know if there is something I can do on my side to help.
Thank you!
|
|
||
Comment 10•1 year ago
|
||
(In reply to Sebastián from comment #9)
Thanks guys. I see this bug is triaged. Do you have any references so I can see how the process continues? I understand that if its triaged as P2 it should be appliable for bounty, but I wait for your response.
I'm not on the bounty committee but my understanding is bounties are usually awarded after a fix is landed, and bounty eligibility usually depends on security severity, which hasn't been set on this bug. Dan, can you help with that?
|
|
||
Comment 11•1 year ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #7)
This pref is enabled on nightly and early beta meaning in the middle of the beta cycle it changes values, so this isn't actually an isolated change.
I think it it makes sense to check the pref when deciding whether to send those cookies or not.
For unrelated reasons I'm restricting the pref to be true only on nightly in bug 1895953, which will at least resolve the brokenness on beta caused by the "early beta" flip-floppiness, and removing it from the "nightly experiments" feature toggle pane (though this should still be fixed in the way you're suggesting here).
|
Reporter | |
Comment 12•1 year ago
|
||
(In reply to :Gijs (he/him) from comment #10)
(In reply to Sebastián from comment #9)
Thanks guys. I see this bug is triaged. Do you have any references so I can see how the process continues? I understand that if its triaged as P2 it should be appliable for bounty, but I wait for your response.
I'm not on the bounty committee but my understanding is bounties are usually awarded after a fix is landed, and bounty eligibility usually depends on security severity, which hasn't been set on this bug. Dan, can you help with that?
Thanks for your response Gijs. I see the severity has been set as S3 but anyway, it is just to know how te process continues. Thanks!
|
Assignee | |
Comment 13•11 months ago
|
||
|
|
Assignee | |
Comment 14•11 months ago
|
||
Initially I said we could probably do this, because at first glace this was an easy to implement solution with low impact. However, I am beginning to think both of these assumptions are not the case.
My main concern is that this may introduce web-compat issues.
If a website assumes that laxByDefault=true and attempts to set a cookie and omits the secure attribute then it's next request another browser (with laxByDefault enabled) would respond with the LAX cookie just fine. While with the proposed patch in comment 13, we would interpret the received cookie as NONE and filter it out in the following request because of the lack of secure.
While the patch above is pretty naive, I'm not sure we would even be able to dig ourselves out of this situation by say adding additional state to every default-same-site cookie at the time of setting with the added cost of complexity, storage, memory footprint and associated performance.
Additionally, with bug 1895953, we no longer will need to worry about the noneRequiresSecure changing during beta. So we only really need to worry about when a user manually changes their pref. At which point I would advise them to also clear their cookies if they are so concerned about this.
This is starting to look like a WONTFIX for me.
Does anyone have any differing thoughts on this?
|
|
||
Comment 15•11 months ago
|
||
This is starting to look like a WONTFIX for me.
Does anyone have any differing thoughts on this?
That's where I was going also. We enforced the rules when the cookie was set (or not) but after that the cookies are what the cookies are.
|
|
Assignee | |
Comment 16•11 months ago
|
||
This is starting to look like a WONTFIX for me. Does anyone have any differing thoughts on this?
We haven't heard otherwise so I am going to close this as WONTFIX. We can reopen if any disagreement surfaces.
|
||
Updated•11 months ago
|
|
|
||
Updated•11 months ago
|
|
||
Updated•11 months ago
|
|
|
||
Updated•9 months ago
|
Description
•