- From: Craig Francis <craig.francis@gmail.com>
- Date: Mon, 13 Jun 2016 17:35:47 +0100
- 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