Menu
We have a cookie set for XSRF/CSRF at the beginning of a user's session. At some point the user navigates to different domain (e.g. for payment), performs some actions, and navigates to our domain. Upon returning to our domain, Firefox and Safari cannot read a cookie set as samesite: Strict, Chrome can. In case of Chrome and Firefox (but not Safari) it does show up under the developer tools section for cookies.
The samesite explanation on MDN explains that upon future requests the cookie will be sent along in the Request headers. For all three browsers, this is the case. What the explanation is inconclusive about is whether it should be possible to read this cookie through document.cookie. For Firefox, Safari and Chrome we can read the 'Lax' cookies, but for only Chrome we can read the 'Strict' cookies. This is also true upon page refresh, but not upon opening a new tab (i.e. only through navigation).
Is this a bug in Safari and Firefox, or in Chrome - or is the spec inconclusive? What would the spec (w3?) be?
It can be easily recreated locally with a webserver with two vhosts, test.internalsite.com and test.externalsite.com, and these pages with some PHP:
<?php
setcookie("CSRFLax", "hiLax", array("path"=>"/", "samesite"=>"Lax", "domain"=>"test.internalsite.com"));
setcookie("CSRFStrict", "hiStrict", array("path"=>"/", "samesite"=>"Strict", "domain"=>"test.internalsite.com"));
?>
<html>
<body>External site
<p><a href="http://test.externalsite.com">Go to External site</a></p>
<p>Document cookie: <script>document.write(document.cookie);</script></p>
</body>
</html>
And
<html>
<body>External site
<a href="http://test.internalsite.com">Go to internal Site</a>
</body>
</html>
680
SameSite=None requires Secure The warning appears because any cookie that requests SameSite=None but is not marked Secure will be rejected. To fix this, you will have to add the Secure attribute to your SameSite=None cookies. A Secure cookie is only sent to the server with an encrypted request over the HTTPS protocol.
Go to chrome://flags and enable (or set to "Default") both #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure. Restart Chrome for the changes to take effect, if you made any changes.
For fixing this, you must add the Secure attribute to your SameSite=None cookies. A Secure cookies will only sent to the server with an encrypted request over the HTTPS protocol. Note: insecure sites (http:) can't set cookies with the Secure directive.
As recommended by our security officer, who was not inclined to discuss the possibility of using 'Lax' cookies instead of 'Secure' cookies (for what I can see as no other reason than semantics), we have implemented a simple workaround by refreshing the page. This works to retrieve the Strict cookies in Chrome and Safari.
var canReadStrictCookie = function(cookies) {
return cookies.toLowerCase().indexOf('mySameSiteSecureCookieName') !== -1;
};
if(document.location.href.indexOf('jmkCheck') === -1 && !canReadStrictCookie(document.cookie)){
document.location.href='?jmkCheck';
}
I would highly recommend you to use the 'Lax' setting if you are in control of the cookies yourself. The name is confusing, it's not lax security (in fact it's more secure than it used to be before same-site was introduced).
95
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With