10

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>
Spork
  • 1,631
  • 1
  • 21
  • 37
  • 1
    Sad that no one replied to your question yet. We are facing the same difficulties at the moment and it looks like a bug to me in Firefox. It can not access any SameSite Cookie even when it's being set *after* opening the page through external link. Safari looks alright. Setting the window.location seems a little odd though. – Till Kolter Jan 25 '20 at 13:04
  • 1
    I'm not quite sure that it's a bug in Firefox, or they are just following the spec and Safari and Chrome are not (so far that was what I thought was going on) – Spork Feb 07 '20 at 13:57
  • I am pretty sure it is a bug, that you can't set any SameSite=strict cookie *after* you land on a page through an external link – Till Kolter Feb 12 '20 at 22:19
  • 2
    Bugs reported for Firefox & Safari: https://bugzilla.mozilla.org/show_bug.cgi?id=1617158 https://bugs.webkit.org/show_bug.cgi?id=208049 – swrobel Jun 15 '20 at 07:19
  • 2
    Luckily, the Firefox bus is solved but the Safari/WebKit bug remains still open. – biolauri Sep 18 '20 at 23:43

1 Answers1

1

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).

Spork
  • 1,631
  • 1
  • 21
  • 37