SameSite those things

In "CSRF of Web Security Vulnerabilities" , we learned that the essence of CSRF is actually the use of cookies that are automatically carried in requests to induce users to initiate requests on third-party sites. In addition to some of the solutions mentioned in the article, the standard also specifically adds SameSite attributes to cookies to circumvent this problem. Chrome supported this attribute in June 2015, followed by Firefox and Safari. SameSite attribute has the following values:

• SameSite=None : Cookies will be sent regardless of cross-site
• SameSite=Lax : Allow some third-party requests to carry cookies
• SameSite=Strict : Only requests from the same site are allowed to carry cookies, that is, the current web page URL is exactly the same as the request target URL

This attribute is suitable for all requests under the webpage, including but not limited to the requests within the webpage such as JS scripts, pictures, iframes, interfaces, etc. in the webpage. It can be seen that None is the most lenient, which is no different from the previous behavior. And Lax and Strict have made restrictions for cross-site situations. Among them, Strict is the most restrictive and does not allow the cookie to be carried in any cross-site situation. Lax is relatively loose, allowing some GET behaviors to be carried after explicit jumps. The following is an example of a standard cookie response SameSite

Set-Cookie: name=lizheming; SameSite=None; Secure

It should be noted that the browser only supports the SameSite=None configuration for HTTPS domain names. So if you want to set SameSite=None , you must also carry the Secure attribute.

Same Site

Same Site literally means the same site, which is different from the Same Origin of the same domain we mentioned before. The main difference between the two is that the criteria for judgment are different. A URL mainly consists of the following parts:

It can be seen that the judgment of the same domain is stricter, and the protocol , hostname port required to be completely consistent. Relatively speaking, the same site judgment in Cookie is relatively loose, mainly based on the public suffix table maintained by Mozilla ( Pulic Suffix List ) using the effective top-level domain name (eTLD)+1 rule to find whether the first-level domain names are the same. Determine whether it is a same-site request.

For example, .org is a valid top-level domain name recorded in PSL, and imnerd.org is a first-level domain name. So https://blog.imnerd.org and https://www.imnerd.org are the same site domain names. And .github.io is also a valid top-level domain name recorded in the PSL, so https://lizheming.github.io and https://blog.github.io are different, and they are cross-domain requests.

In third-party services like GitHub/GitLab Pages, Netlify, and Vercel that provide subdomains for users to build websites, the same-site judgment feature of eTLD is often very useful. By adding the domain name that was originally a first-level domain to the eTLD list, the browser thinks that the complete domain name with the user name is the first-level domain, effectively solving the problem of cookie sharing between different user sites.

eTLD

The full name of eTLD is effective Top-Level Domain, which is different from the top-level domain name of Top-Level Domain that we usually understand. The eTLD is recorded in the aforementioned PSL file. The TLD also has a list of records, which is Root Zone Database . All root domain lists are recorded in RZD, and there are many strange and varied suffixes among them.

The emergence of eTLD is mainly to solve the .com.cn , .com.hk , .co.jp which looks like a first-level domain name but actually needs to exist as a top-level domain name. Here is another interesting thing to share. In May 2020, there was an incident in which ac.cn The reason is that ac.cn is the registered eTLD domain name applied by the Chinese Academy of Sciences. Alibaba Cloud’s script for detecting domain names does not understand the specifications. It does not use the PSL list to find the first-level domain names. Instead, it uses the . segmentation method to find them. Eventually all *.ac.cn domain due ac.cn the domain name does not resolve all of the record leads to hang. And we now know ac.cn this domain is eTLD domain name, it is certainly not the record.

Schemeful Same Site

In Chrome 86/Firefox 79, the browser has added a Schemeful Same Site option, and the protocol has also been added to the judgment rules of Same Site. But it is not a complete unequal judgment. It can be understood whether there is a difference in SSL. For example, http:// and https:// cross stations, but wss:// and https:// are at the same station, and ws:// and http:/ are also regarded as the same station.

Chrome can enter chrome://flags/#schemeful-same-site browser to find the configuration and open it.

Lax

We know that Internet advertisements mark user IDs under fixed domain cookies to record the user's behavior to achieve the purpose of accurate recommendation. With the rectification of global privacy issues, but also to better avoid CSRF issues, the browser in Chrome 80 changed the default SameSite rule from SameSite=None to SameSite=Lax . After setting to SameSite=Lax , all cross-site resource requests in the page will not carry cookies. Since cookies are not carried for cross-site requests, CSRF cross-site attacks are impossible to talk about, and advertisers cannot fix user IDs to record behavior.

This is definitely a good thing for users. But for our technical students, this is undoubtedly an obstacle set by the upstream for us. Because the business does have multiple domain names, and cookies need to be passed in these domain names. For example, multiple sites use SSO login, access to a unified verification code service, front-end and server-side interfaces belong to two domain names, etc., will all be affected by this modification.

This modification has a wide range of influences and requires website maintainers to spend a lot of time to modify the adaptation. After Chrome 80 was released in February 2020, the world began to face the impact of the new crown epidemic. Considering that the follow-up version of the epidemic problem has temporarily rolled back this feature ( related link ), the full operation was finally carried out in Chrome 86.

For websites affected by this feature, you can choose the following adaptation methods:

1. Use JWT and other non-Cookie communication methods
2. SameSite=None;Secure attribute configuration for Cookie
3. Add Nginx proxy to all cross-domain interfaces to keep it in the same domain as the page

Each method requires some trade-offs. The first method of replacing cookies is very costly, especially in the case of external business docking, which is basically impossible. The third method, by changing the cross-domain to the same-domain forwarding method, may cause the online traffic to increase exponentially, which is also a factor to be considered. The second setting to None seems to be a relatively simple method, but it also has many limitations.

1. SameSite=None;Secure only supports HTTPS pages, so if there is an HTTP scenario, you need to consider jumping to HTTPS or choosing other solutions;
2. Since the SameSite attribute was added later, some old browsers (actually IE) will ignore cookies with these attributes. Therefore, two Set-Cookie response headers that are SameSite attribute and the SameSite Those not supported will get what they need;
3. In some versions of Safari, SamteSite=None equivalent to SameSite=Strict so some Safari scenes require special processing and not be issued ( related link );

In summary, the method of using proxy forwarding is the one I recommend. In addition to being not so green, it is good to handle compatibility issues.

SameParty

SameSite=Lax broke our idea of passing cookies across sites, but there is indeed such a scenario in actual business. For example, Google itself has a lot of domain names. If these domain names all need to share login cookies, it may be very difficult. In response to this situation where an entity has multiple domain names and needs to share cookies, some people (that’s actually Google’s classmates) proposed [SameParty](
https://github.com/cfredric/sameparty) The concept of

The proposal proposes a SameParty . When the cookie is marked with this attribute, it can be shared under the same primary domain. How to define different domain names to belong to the same primary domain? Mainly rely on another feature first-party-set first-party set. It stipulates that the URL /.well-known/first-party-set under each domain name can return a configuration file of the first-party domain name. In this file, you can define which first-party domain name the current domain name belongs to, and which member domain names are under the first-party domain name.

Of course, the use of a fixed URL will generate additional requests, which will affect the response of the page. You can also directly use the Sec-First-Party-Set response header to directly specify the attribution of the first-party domain name.

However, the W3C TAG team has strongly rejected the proposal ( source ). W3C believes that the proposal redefines the boundaries of the website sandbox, and the impact may not only be as simple as cookie sharing, but also privacy settings such as microphones, cameras, and geographic information need to be reassessed.

At the same time, the proposal may be inconsistent with user expectations. If Google and Youtube are defined as first-party websites for sharing, then Google can easily obtain user behavior on Youtube, which may not be what users want.

The full name of the W3C TAG group is the Technical Architecture Group, which is the W3C Technical Architecture Group. TAG is a special group of W3C that focuses on Web architecture management. Its mission is to seek consensus for the design principles of the Web architecture, and to sort out and clarify these design principles when necessary, to help coordinate the W3C internal and external architecture definition and research and development across different technologies. Basically, it can be considered as a group defined by the basic specifications of the Web. In addition, Tim Berners-Lee, the father of the World Wide Web, is also in the TAG group.

However, what the W3C said is reasonable and unreasonable, and it can't stop Chrome from implementing this function. The related logic of SameParty has been added in Chrome 89, but it is not currently enabled by default. At present, you can see the SameParty attribute column of Cookie in DevTools. Edge also supports this feature in the same version because it uses Chromium. Only in charge of the specification, not in charge of the implementation, when a certain browser achieves "hegemony", the situation of W3C becomes awkward.

FLoC

In addition to SameSite's impact on single-entity and multi-domain sharing of cookies, the biggest problem is actually the behavior of Internet advertisements to obtain users. Since the advertisement mounting page and the advertisement are not in the same domain, the advertisement cannot obtain the user ID used to mark the user to cluster the user behavior. In order to solve this problem, someone (in fact, a classmate of Google) put forward the Federated Learning of Cohorts alliance learning cohort proposal.

It is different from the previous method of using Cookie ID tags to directly pass user behavior data to the advertiser's website for processing. It proposes a document.interestCohort() , which converts user behavior into keywords without personal privacy locally, which not only circumvents user privacy issues, but also solves the problem of accurate advertising.

But this seemingly good things but was strong resistance to the major sites and browsers, BRAV , Vivaldi , DuckDuckGo , GitHub and Edge, Firefox, Safari ( source ) all have issued Refuse to support opinions and actions.

The main concern of the community is that the addition of new features may increase the feature value to provide a broader entrance to privacy sniffing. And through this API, user browsing data that could not be obtained programmatically due to permission can be obtained. Currently Chrome already supports this feature, but Flag needs to be turned on to support it. amIFLoCed is a website used to detect whether your browser has the FLoC tracking feature enabled. You can use it to detect whether your browser applies this feature.

postscript

In order to solve the CSRF problem, Chrome forced SameSite=Lax as the default configuration. What followed was not only the coordination and modification of global developers, but also the unsatisfaction of existing scenes. In order to meet the existing scenarios, two solutions, SameParty and FLoC I wonder if this behavior can become the browser's internal scrolling behavior?

SameSite attribute itself is not a problem, but I personally think that it should be a choice for CSRF problems. It is a bit uncomfortable for the SameSite=Lax Most enterprise projects have adopted other CSRF prevention methods to circumvent this problem, and the Lax configuration has compatibility problems, which can't let us completely avoid the worries of CSRF.

With the intensification of global privacy issues, I don’t know if there are any new proposals that require our global developers to pay for it.

reference:

• cover image source
• 《SameSite cookies explained》
• 《SameSite cookie recipes》
• 《Schemeful Same-Site》
• 《Understanding "same-site" and "same-origin"》
• https://www.chromestatus.com/feature/5088147346030592
• https://www.chromium.org/updates/same-site
• https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/