Cookies with SameSite=strict not sent for initial GET requests in special cercumstances
Reported by
luzar.da...@gmail.com,
Mar 22 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36 Steps to reproduce the problem: 1. Initialize a SameSite=strict (auth) cookie 2. Do *any* of the following: a) duplicate tab b) close tab & `ctrl + shift + t` to re-open it c) navigate to different origin, and use `back` button to navigate back d) deliberately crash the tab via Chrome Task Manager, and refresh it What is the expected behavior? The initial GET request to the server to fetch `index.html` should send the auth cookie alongside the request. What went wrong? The SameSite=strict cookie is not sent until later requests. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 57.0.2987.98 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Happens on Canary channel as well. AFAIK other browsers do not yet implement it so can't repro. Sorry for not tagging the issue, it let me only choose from blink categories FSR. Related: https://bugs.chromium.org/p/chromium/issues/detail?id=677164 https://bugs.chromium.org/p/chromium/issues/detail?id=626243
,
Mar 23 2017
,
Mar 23 2017
Can you collect a net-internals trace? https://dev.chromium.org/for-testers/providing-network-details
,
Mar 24 2017
Sent via email in case there is some sensitive info.
,
Mar 24 2017
,
Mar 27 2017
,
Mar 29 2017
It looks to be out of scope from TE end, please add the steps if it can be reproduced and remove the label "TE-NeedsTriageHelp".
,
Apr 5 2017
Yeah. It looks like we're still not getting the initiator right in the NavigationEntry. We should get this fixed.
,
Nov 10 2017
,
Feb 18 2018
,
Mar 16 2018
Not 100% sure if this is directly related, but it seems like a "special circumstance" in which the cookies should be sent. To prevent tabnabbing, scripts like blankshield (https://github.com/danielstjules/blankshield) will listen for the click event and prevent the default browser behavior of opening a new tab. Inject a hidden iframe that opens the new tab, then immediately remove the iframe. The iframe doesn't have a domain, it is location is "about:blank". When the iframe opens the new tab/window (via window.open(...) in it's context) it should send the SameSite=Strict cookies in the request. This was working until M65. I am not sure if it was intentionally removed. I can understand the case with "Site A" opens "Site B" via "about:blank" iframe and not sending the cookies, but what about the case where "Site A" opens "Site A" via "about:blank"? That seems like it should send the cookies.
,
Apr 25 2018
Not really a network issue - not sure if this was fixed. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by luzar.da...@gmail.com
, Mar 22 2017