[ad_1]
Slowly but surely, web developers have the tools to tame the crowded and often unsafe world of the browser cookie.
The latest great idea to date is an IETF standard called SameSite (aka RFC6265bis), promoted by Google and Mozilla since 2016. The first one announced this week that it was going to start using Google Chrome in more ways aggressive from version 76 in July.
Cookies look simple on the surface: it's a small amount of textual data that a website can ask your browser to keep in memory, and your browser will return to it each time the browser retrieves a page, a picture or anything else. For security reasons, cookies can only be transferred to the domain that configured them.
The most common use of cookies is the identification of the user: a site stores an identifier in a cookie and the browser returns this identifier to each request so that the site knows who he is talking to. It's this simple technique that allows sites to authenticate and customize.
What gives a bad name to cookies are third-party cookies, usually set up by advertisers or social media giants to track users on different sites.
For example, if a user visits a page on example.org with a Facebook button, their browser retrieves that button from facebook.com as the page loads. As with any HTTP interaction, the browser will include all cookies from facebook.com in the request to Facebook, as well as a referent header showing the query page on example.org.
If you're signed in to Facebook (and sometimes even if they're not), this button request tells Facebook who you are, what page you visited, and when.
If a social media or advertising agency can convince enough sites to include code hosted on a domain they own, they can turn these cookies into inter-site followers, which map the behavior and interests of each user while browsing the Web.
And that's why some users regularly delete browser caches or use ad blocking or privacy plug-ins – cumbersome but effective solutions that can prevent sites from working properly.
The consequences of this behavior are not limited to monitoring, they can also lead to major security risks, such as Cross-Site Request Forgery (CSRF) attacks.
For simplicity, if a user leaves a site (a bank, for example) without disconnecting, it is theoretically possible that a second site, malicious, encourages this user to send to the bank invisibles requests that exploit the fact that the user is still active. logged.
The biggest weakness of this architecture is perhaps the assumption that even if a browser can transmit a cookie, it should.
How will SameSite help?
The addition of SameSite support to Chrome (Firefox, Safari and Edge added an experimental support last year) will force web developers to control cookies with the help of the SameSite attribute of Set-Cookie header, which can be Strict, Released, or No.
In reality, it is a way of controlling which cookies can be sent by the browser and under what circumstances, removing the notion that a browser should send a cookie to a site simply because it is not safe to send a cookie to a site. he can.
A cookie set on Strict will only be accessible when you visit the domain that configured it. If you visit another site containing content from this domain, cookies will not be sent home.
The Strict setting is also a long-awaited way of countering the risk of CSRF attacks.
Alternatively, the setting Released will allow cookies to be made available to third parties via HTTP GET requests, but not by other methods such as POST. This will not be enough to block a lot of follow-ups, but CSRF attacks will be dulled.
Finally, there is No, which simply allows access to a cookie in the same way as today.
Good news for security and, with fewer cookies that fly, privacy too. Cookies will either be the same site and restricted, or one of two states of the site.
Ben Galbraith, director of Chrome Product Management at Google:
This will also allow browsers to provide clear information about the sites that install these cookies, so that users can knowingly choose the use of their data.
Google would also seek to limit cross-site cookies when SameSite = None HTTPS connections to enhance the effect of privacy, he added.
Unlike many competitors in the advertising industry, Google has little to lose from SameSite (ie the popularity of ubiquitous Chrome and Google services, including DoubleClick ads), which is driving controversial.
This is another example of the privacy paradigm on the Internet: large, high-tech companies seem happy to promote privacy protection as long as it does not stop them from looking behind the curtain.
Cookie reform will also require more than the invention of new cookie attributes. Today, most sites set cookies without SameSite attribute and it will take time to support the new format.
Chrome 76 shows how Google could speed up this process. He introduces a cookies without the same site must be secure indicator that users can set so that Chrome assumes all cookies without SameSite value are put to SameSite = Lax.
If Google applies the approach used for the adoption of HTTPS to cookies, we can expect this indicator to be set by default and scaling up in later versions.
[ad_2]
Source link