W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2016

SameSite=Strict cookies for a user entered URL

From: Craig Francis <craig.francis@gmail.com>
Date: Mon, 13 Jun 2016 17:35:47 +0100
Message-Id: <E2FEA02E-C23E-4459-BE86-45C947959C33@gmail.com>
To: security-dev <security-dev@chromium.org>, WebAppSec WG <public-webappsec@w3.org>
Hi,

I was wondering about the security vs usability in how SameSite=Strict cookies work.

At the moment (in Chrome 51 - 53 at least), if you're on a website, and copy/paste a URL for the current website in to the current tabs address bar, the SameSite=Strict cookies are sent in that request.

But if you open a new tab, paste the URL, the requested page does not include the SameSite=Strict cookies.

---

From a security point of view, it's possible that the user has been given a malicious URL to navigate to, so maybe the correct behaviour is to block all SameSite=Strict cookies where the Referrer isn't the current website.

But, if the user is on a particular page, and they want to keep that page open; they might right hand click on the link they want to view, copy the link address (not using the "open link in new tab" feature), open a new tab, and paste the URL... so when that page loads, they need to login again.

Or, if they have a bookmark in their browser, or a link in an email (normal email client, not a webmail client); then every time they follow those links, should they need to login again?

---

Personally I have a bit more of a complicated problem, where I have a cookie that defends against CSRF, but that's a little tricker to explain. So I'm wondering if the slightly less secure approach might be better, as at the moment I'm getting a few complaints, where I think I'll have to drop back to SameSite=Lax (as Strict might be a little too Strict).

Craig





And while it's protected, I have raised a Chrome bug for this:

https://crbug.com/619603


And the spec is at:

https://tools.ietf.org/html/draft-west-first-party-cookies-07
Received on Monday, 13 June 2016 16:36:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:20 UTC