In “CSRF for Web Security Vulnerabilities”, we learned that the essence of CSRF is actually to induce users to initiate a request on a third party site by taking advantage of the feature that cookies will automatically carry in the request. In addition to some of the workarounds described in this article, the standard adds the SameSite attribute specifically for cookies to circumvent this problem. Chrome added support for this property in June 2015, with Firefox and Safari following soon after. The SameSite attribute has the following values:

  • SameSite=None: Cookies are sent across sites or not
  • SameSite=Lax: Allows some third-party requests to carry cookies
  • SameSite=Strict: Cookies are only allowed for peer requests, that is, the current web page URL is exactly the same as the request target URL

This attribute applies to all requests under the web page, including but not limited to javascript scripts, images, iframes, interfaces and other requests within the web page. You can see that None is the loosest, just like the previous behavior. Lax and Strict both limit cross-station situations. Strict is the strictest and does not allow the Cookie to be carried in any cross-site situation. Lax is a little looser, allowing some explicit jump GET behavior portability. Here is an example of a standard Cookie response with the SameSite attribute:

Set-Cookie: name=lizheming; SameSite=None; Secure
Copy the code

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

Same Site

Same Site, Same Origin, Same Origin, Same Site, Same Origin. The difference between the two mainly lies in the different criteria of judgment. A URL consists of the following parts:

It can be seen that the judgment of homology is strict, and the three parts of protocol, hostname and port need to be completely consistent. In comparison, the same-site judgment in cookies is relatively loose, mainly based on the Pulic Suffix List maintained by Mozilla to determine whether the first-level domain names searched by using eTLD +1 rule are the same.

For example,.org is a valid top-level domain recorded in PSL, and imnerd.org is a first-class domain. So https://blog.imnerd.org and https://www.imnerd.org are co-located domain names. And. Making. IO and record in the PSL efficient top-level domain, so the primary domain name https://lizheming.github.io and https://blog.github.io is not the same, they are two cross-domain request.

ETLD’s site-determination feature is often useful in third-party services such as GitHub/GitLab Pages, Netlify, and Vercel that provide subdomain names for users to set up sites. The problem of Cookie sharing among different user sites is effectively solved by adding domain names that were originally level 1 domains to the eTLD list and making browsers think that the complete domain name with user name is level 1 domain.

eTLD

ETLD stands for effective top-level Domain, which is different from the effective top-level Domain. ETLD is recorded in the PSL file mentioned earlier. The TLD also has a list of records, the Root Zone Database. RZD has a list of all the root fields, and some of them have strange suffixes.

The emergence of eTLD is mainly to solve the situation that.com.cn,.com.hk,.co.jp look like a level 1 domain name but actually need to exist as a top-level domain name. Here you can also share an interesting thing. In May 2020, there was an event in which all the ac.cn suffix websites of Aliyun were resolved and suspended. The reason is that AC.cn is the eTLD domain name applied by the Chinese Academy of Sciences. And Ali cloud detection domain name record script does not understand the specification, did not use PSL list to find the level of domain name, but used. In the form of segmentation to find. In the end, all *.ac.cn domain names failed to be resolved because ac.cn was not recorded. However, we now know that ac.cn is an eTLD domain name, and it certainly cannot be put on record.

Schemeful Same Site

With Chrome 86 or Firefox 79, the browser adds an option for Schemeful Same Site, which adds the protocol to the judgment rule of the Same Site. But it’s not a complete unequal judgment, and you can understand the difference between SSL and not SSL. For example, http:// and https:// are cross-site, but WSS :// and https:// are co-site, as are WS :// and HTTP :/.

For Chrome, type Chrome ://flags/#schemeful-same-site to find the configuration and enable it.

Lax

We know that Internet advertisements mark user IDS under fixed domain cookies and record user behaviors to achieve the purpose of accurate recommendation. In Chrome 80, the browser changed the default SameSite rule from SameSite=None to SameSite=Lax in response to global privacy issues and to better circumvent CSRF issues. After setting SameSite=Lax, all cross-site resource requests within the page do not carry cookies. Because cookies are not carried for cross-site requests, CSRF cross-site attacks are not possible, and advertisers cannot fix user ids to record behavior.

This must be a good thing for users. But for our technical students, this is undoubtedly an obstacle set by the upstream for us. Because businesses do have multiple domain names, and cookies need to be passed in these domain names. For example, multiple sites use SSO to log in, access the unified captcha service, and the front-end and server interfaces belong to two domain names.

This modification is widely influential and requires the website maintainer to spend a lot of time to adapt. When Chrome 80 was released in February 2020, the world began to face the impact of the COVID-19 pandemic. This feature was temporarily rolled back in subsequent versions (link) in consideration of the pandemic, and was eventually fully implemented in Chrome 86.

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

  1. Use other non-cookie communication methods such as JWT
  2. For the CookieSameSite=None; SecureThe configuration properties
  3. Nginx proxies are added to all cross-domain interfaces to keep them codomain with the page

Each approach requires some trade-offs. The first way to replace cookies is very expensive, especially impossible in the case of external business docking. The third way, by changing the cross-domain forwarding mode into the same-domain forwarding mode, may bring about the double increase of online traffic, which is also a factor to be considered. The second option, set to None, seems to be the simpler option, but it has a number of limitations.

  1. SameSite=None; SecureSince only HTTPS pages are supported, you need to switch to HTTPS or choose another solution in HTTP scenarios.
  2. Due to theSameSiteProperties were added later, and some older browsers (IE in fact) ignore cookies with these properties, so they need to be delivered unconfigured at the same timeSameSiteProperties and ConfigurationSameSiteTwo attributesSet-CookieThe response header, so that the supported and unsupported ones get what they want;
  3. In some versions of Safari it willSamteSite=NoneIs equivalent toSameSite=StrictTherefore, some Safari scenarios require special processing and do not deliver (A link to the);

To sum up, the proxy forwarding method is recommended by me. In addition to being less green, it is good to deal with compatibility problems.

SameParty

SameSite=Lax breaks the idea of sending cookies across sites, but it does happen in business. Google, for example, has so many domain names that it would be difficult to share login cookies. In this case, an entity with multiple domain names needed to share cookies, someone (actually a classmate at Google) came up with the concept of SameParty.

The proposal introduced SameParty’s new Cookie attribute, which allows cookies marked with this attribute to be shared in the same primary domain. So how do you define different domain names that belong to the same primary domain? It relies on another feature called first-party-set. It states that the URL /.well-known/first-party-set under each domain name can return a first-party domain name profile. In this file, you can define which first-party domain name the current domain name belongs to and which member domain names exist under the first-party domain name.

Of course, using a fixed URL creates additional requests that affect the response of the page. You can also directly specify the owning first-party domain name using the sec-first-party-set response header.

However, the W3C TAG group has strongly rejected the proposal (source). The W3C believes that the proposal redefines the boundaries of the web sandbox and may have implications beyond Cookie sharing, including privacy Settings such as microphones, cameras, and geographic information that need to be reassessed.

At the same time, the proposal may be inconsistent with users’ expectations. If Google and Youtube are defined as first-party sites to share, Google can easily obtain users’ behavior on Youtube, which may not be desired by users.

The W3C TAG Group stands for the Technical Architecture Group. TAG is a special group of THE W3C that focuses on managing Web architectures. Its mission is to seek consensus and, where necessary, tease out and clarify design principles for Web architectures, helping to coordinate architecture definitions and research and development within and outside the W3C across different technologies. You can think of it basically as a group of Web foundation specification definitions. Tim Berners-Lee, creator of the World Wide Web, is also on the TAG team.

But the W3C’s argument is right or wrong, and it won’t stop Chrome from implementing this feature. SameParty logic has been added to Chrome 89, but it is not currently enabled by default. You can currently see the SameParty property column for cookies in DevTools. Edge also supports this feature in the same version thanks to Chromium. Being in charge of the specification, not the implementation, puts the W3C in an awkward position when one browser achieves “hegemony.”

FLoC

In addition to affecting cookies shared by single entities and multiple domains, the biggest problem with SameSite is Internet AD acquisition behavior. Since the AD mount page and the AD are not in the same domain, the AD cannot be used to tag the user ID to cluster the user behavior. To solve this problem, someone (actually a classmate at Google) proposed Federated Learning of Cohorts Alliance Learning queues.

This is different from the previous approach of using Cookie ID tags to transmit user behavior data directly to the advertiser’s website. It has proposed a new API, Document.Interestcohort (), to convert users’ behavior locally into keywords without personal privacy, which not only avoids user privacy issues, but also solves the problem of accurate advertising.

However, this seemingly beautiful thing has been strongly resisted by various websites and browsers, with Brav, Vivaldi, DuckDuckGo, GitHub and Edge, Firefox and Safari (sources) all Posting opinions and actions that refuse to support it.

The community’s main concern is that the addition of new features may increase eigenvalues and provide a wider entry point for privacy sniffing. The API also allows access to user browsing data that previously could not be accessed by the program due to permissions. Chrome already supports this feature, but requires Flag to be enabled. AmIFLoCed is a website that detects if your browser has enabled FLoC tracking.

Afterword.

To address the CSRF issue, Chrome has forced SameSite=Lax as the default. As a result, not only did developers around the world cooperate with the changes, but the existing scenes were not satisfied. Two solutions, SameParty and FLoC, were proposed to meet the existing scenario. Can this behavior become the browser’s inroll behavior?

The SameSite property itself is fine, but I think it should be an alternative to the CSRF problem, and the browser defaults to SameSite=Lax. Most enterprise projects already use other CSRF defenses to circumvent this problem, and the Lax configuration has compatibility issues that don’t make CSRF completely irrelevant.

With privacy issues heating up around the world, I wonder what new proposals are coming up that we, the world’s developers, will have to pay for.

References:

  • Source of cover art
  • SameSite Cookies Explained
  • SameSite Cookie Recipes
  • The Schemeful Same – Site”
  • Understanding “same-site” and “same-origin”
  • www.chromestatus.com/feature/508…
  • www.chromium.org/updates/sam…
  • Hacks.mozilla.org/2020/08/cha…