https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/
Cookies like to get around. They have no scruples about where they go save for some basic constraints relating to the origin from which they were set. I mean have a think about it:
If a website sets a cookie then you click a link to another page on that same site, will the cookie be automatically sent with the request? Yes.
What if an attacker sends you a link to that same website in a malicious email and you click that link, will the cookie be sent? Also yes.
Last one: what if an attacker directs you to a malicious website and upon visiting it your browser makes a post request to the original website that set the cookie - will that cookie still be sent with the request? Yes!
Cookies just don't care about how the request was initiated nor from which origin, all they care about is that they're valid for the requested resource. "Origin" is a key word here too; those last two examples above are "cross-origin" requests in that they were initiated from origins other than the original website that set the cookie. Problem is, that opens up a rather nasty attack vector we know as Cross Site Request Forgery or CSRF. Way back in 2010 I was writing about this as part of the OWASP Top 10 for ASP.NET series and a near decade on, it's still a problem.
This is a followup to our previous story that provides some excellent details and explanations.
Related Stories
WTF is Chrome's SameSite cookie update? - Digiday:
On February, 4, Google is set to roll out a new Chrome update that promises a bunch of new features designed to make the browser faster and more secure — including a new approach to cookies.
The SameSite update will require website owners to explicitly state label the third-party cookies that can be used on other sites. Cookies without the proper labelling won't work in the Chrome browser, which has 64% of the overall browser market, according to Stacounter.
Google first announced in May last year that cookies that do not include the "SameSite=None" and "Secure" labels won't be accessible by third parties, such as ad tech companies, in Chrome version 80 and beyond. The Secure label means cookies need to be set and read via HTTPS connections.
Right now, the Chrome SameSite cookie default is: "None," which allows third-party cookies to track users across sites. But from February, cookies will default into "SameSite=Lax," which means cookies are only set when the domain in the URL of the browser matches the domain of the cookie — a first-party cookie.
Any cookie with the "SameSite=None" label must also have a secure flag, meaning it will only be created and sent through requests made over HTTPs. Meanwhile, the “SameSite=Strict” designation restricts cross-site sharing altogether, even between different domains that are owned by the same publisher.
Mozilla’s Firefox and Microsoft's Edge say they will also adopt the SameSite=Lax default.
Temporarily rolling back SameSite Cookie Changes
With the stable release of Chrome 80 in February, Chrome began enforcing secure-by-default handling of third-party cookies as part of our ongoing effort to improve privacy and security across the web. We've been gradually rolling out this change since February and have been closely monitoring and evaluating ecosystem impact, including proactively reaching out to individual websites and services to ensure their cookies are labeled correctly.
However in light of the extraordinary global circumstances due to COVID-19, we are temporarily rolling back the enforcement of SameSite cookie labeling, starting today. While most of the web ecosystem was prepared for this change, we want to ensure stability for websites providing essential services including banking, online groceries, government services and healthcare that facilitate our daily life during this time. As we roll back enforcement, organizations, users and sites should see no disruption.
Also at The Verge, Android Police, Engadget, and Forbes.
Previously: WTF is Chrome's SameSite Cookie Update?
Promiscuous Cookies and their Impending Death via the SameSite Policy
(Score: 2) by bradley13 on Sunday January 05 2020, @08:59AM (1 child)
This looks like a good solution. If you are sent from one site to another, it makes sense for the new site to be able to recognize you ("lax" cookies). However, that site may also have sensitive information (e.g., authentication tokens) that should not automatically be sent when coming from an external site.
It seems to be that they should go one step farther: I don't see any legitimate use-case for allowing an external site to initiate a POST. Limit external references to GET requests. That would also eliminate a lot of potential security issues...
Everyone is somebody else's weirdo.
(Score: 0) by Anonymous Coward on Sunday January 05 2020, @12:59PM
API requests?
(Score: 3, Informative) by The Mighty Buzzard on Sunday January 05 2020, @11:41AM
Cookies are HTTP headers and work with any kind of HTTP request; they are not limited to POST requests.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Sunday January 05 2020, @07:02PM (1 child)
What problem?
In end cookies are a waste of effort. And by design in secure in every way.
(Score: 3, Insightful) by Runaway1956 on Sunday January 05 2020, @08:27PM
Yes, true, at least 95% true. But, what Google appears to be saying is, they are going to stop facilitating that insecurity. If they only cease from aiding and abetting, that will mean a lot. Alas, I don't really trust Google as the gatekeeper. I'll be keeping my addons that actively destroy cookies when a session ends, and block 3rd party cookies altogether.
Don't let your guard down, just because Google says that Google has made the internet safer for you.
Abortion is the number one killed of children in the United States.
(Score: 0) by Anonymous Coward on Monday January 06 2020, @08:15PM (2 children)
It'd be great if the summary included the solution as well as the problem.
I tried reading the article, but it got technical quickly, and I am not a web-dev.
What did they actually do to solve the problem?
(Score: 2) by hendrikboom on Tuesday January 07 2020, @01:36PM (1 child)
The problem is that cookies are promiscuous by default, and that therefore there are lots and lots of them, waiting to be exploited by bad actors.
The cure is to make them faithful to their originating site by default.
This means that any cookie that is to be abused by adulterous bad actors will have to be explicitly labeled as promiscuous.
There will be fewer promiscuous cookies as a result, and it will be easier to track them down and eliminate them.
Besides why would site want the cookies it sets be easily abused by their competitors?
Would you want a cookie if you don't know where it's been?
-- hendrik
(Score: 2) by hendrikboom on Tuesday January 07 2020, @01:37PM
Note: I am not talking about Dagwood Bumstead's daughter. I have no reason to believe she's promiscuous.