The author is in the long front road, if the article has incorrect, inappropriate place please comment to tell me, very thank you! 😊

preface

At the beginning of the year, our team encountered such a problem when docking with the operator center: the login status was invalid because cookies could not be transmitted after successful login. After investigation, when the server sets the Cookie to the client through the set-cookie response header, Chrome sends a warning: the default SameSite of the Cookie is Lax, so some cross-site requests do not carry the Cookie.

In Chrome 80, which was released on February 4, 2020, the default setting of cookies without a SameSite value was set to SameSite=Lax in order to reduce the use of insecure third-party cookies.

For starters, I have a question: What is the SameSite property? Why is Chrome doing this? How do we respond to this change? With these questions in mind, follow along with this article to understand More about SameSite.

CSRF attacks

To understand the SameSite properties, it is necessary to mention the CSRF attack.

CSRF stands for cross-site request forgery. It means that some malicious websites will induce users to send cross-site request to the attacked website, and use the login status obtained by users to bypass the background user authentication, so as to impersonate users to perform an operation on the attacked website.

For example, a CSRF attack of the GET type is very simple and requires only one HTTP request:

<img src="http://bank.example/withdraw? amount=10000&for=hacker" >Copy the code

The user has logged in to trusted website A and saved the login status. After he visits the malicious page containing the IMG, the browser automatically issues an HTTP request, and Bank.Example receives a cross-domain request containing the user’s login information to transfer $10,000 to the hacker’s account.

Cookies are often used to store user identity information as a key data for maintaining login status between the browser and the server. And malicious websites use cookies to achieve CSRF attacks.

Cookies that match the domain of the current site, that is, what is displayed in the browser’s address bar, are called first-party cookies. Similarly, cookies from domains other than the current site are called third-party cookies. In addition to being used for CSRF attacks, third-party cookies are also used for user tracking, which has become a sharp tool for major advertising and shopping websites to spy on user privacy.

Therefore, to prevent access to unknown outlands, CSRF attacks, and user tracking, starting with Chrome 51, a new SameSite attribute is added to the browser’s Cookie.

SameSite properties

The introduction of the SameSite property for cookies will allow users to specify whether to restrict cookies to requests from the SameSite. It can set three values:

  • Strict: prohibits third-party cookies. Cookies are carried only when the current web URL is exactly the same as the requested target URL.
  • Lax allows some third-party requests to carry cookies, as shown in the figure below.
  • None sends cookies whether it is cross-site or not

It is important to understand the difference between homologous/cross-domain and same-site/cross-site.

Same-origin in the Browser SOP indicates that two urls have the same protocol, host name, or port. For example, www.baidu.com/pages/… , the protocol is HTTPS, the host name is www.baidu.com, and the port is 443.

As the security cornerstone of the browser, the same-origin policy is strict in its “same-origin” judgment. In contrast, the “same-site” judgment in cookies is relatively loose: as long as the eTLD+1 of two urls is the same, protocol and port need not be considered. ETLD indicates a valid top-level domain name, such as.com,.co. UK, and.github. IO. ETLD +1 indicates a valid top-level domain name + a second-level domain name, such as Taobao.com.

For example, www.baidu.com and www.juejin.com are cross-stations, www.a.juejin.com and www.b.juejin.com are co-stations, www.a.juejin.com:80 and www.a.juejin.com:3000 are cross-domain.

To prevent CSRF attacks, we can set some critical cookies to Strict or Lax mode according to the actual situation. In this way, these critical cookies will not be sent to the server during cross-site requests, thus disabling the CSRF attacks of hackers.

Although this SameSite property is widely supported, it is unfortunately not widely adopted by developers and still leaves users vulnerable to CSRF and unintentional information leakage. So Chrome adopts the SameSite default policy described at the beginning, setting cookies that do not declare a SameSite value to SameSite=Lax by default. This will make some systems using third-party cookie scenarios, resulting in login exceptions, system crashes and other major problems.

The solution

The SameSite default policy has an impact that cannot be overlooked. Some people suggest changing the browser Settings of the client and disabling “SameSite by Default cookies”, which is simple and rude, but this is just a quick fix. It goes against the biggest advantage of BS architecture applications, developers cannot install and deploy for all clients. So what can developers do about it? Here are a few ways to deal with it.

Ngnix reverse proxy solves cross-domain problems

Since three-party cookies are not supported, let’s solve the cross-domain problem. I won’t go into details in this article.

Set SameSite to None

The server sets the header of response to set-cookie: SameSite=None to allow cross-site requests to send cookies.

But there are two points to note:

  1. HTTP interfaces do not support SameSite= None

If you want to add SameSite= None, then the Cookie must also have the Secure attribute, which means that the Cookie will only be sent over HTTPS. This also means that your site will need to migrate to HTTPS, which makes your site more secure.

Set-cookie: key=value; SameSite=None; Secure
Set-cookie: key=value; Secure
Copy the code
  1. SameSite= None in some browsers

Safari on IOS 12 and some older versions of Chrome misread SameSite= None as SameSite=Strict, Therefore, the server must perform user-Agent detection when sending the set-cookie response header to determine whether SameSite= None is added.

The Electron useSessionCookies

However, the server-side approach to modifying the response header is not suitable for our current scenario because we cannot modify the operator center interface. Our product FIP is based on Electron, and Electron is based on Node.js and Chromium, so we turned to Electron to see if it had a solution.

After repeatedly reading the official documents of Electron, it is found that Electron uses Chromium’s native network library to send HTTP/HTTPS requests, and its request objects have the following two mysterious parameters:

  • Session Object (Optional) – The session instance associated with the request.
  • UseSessionCookies Boolean (Optional) – Whether to send cookies with the request from the provided session.

The session instance is responsible for managing browser sessions, cookies, etc. When the server returns a set-cookie response header, Electron stores the cookie in the session instance associated with the request. When useSessionCookies are true, the next request sent to the server will carry cookies from the previously stored Session instance. While this bypasses the SameSite default policy, it may cause some security issues.

summary

This article introduces the background and function of sameSite attribute, introduces the impact of Chrome80+ sameSite default policy, and finally proposes several solutions.

While Chrome’s change is a step up for developers, it also demonstrates Chrome’s focus on front-end security and user privacy and encourages developers to take the initiative to provide a safer experience for users, rather than relying on the browser’s default behavior.

reference

Predict the SameSite property of cookies in a recent interview

Ruan Yifeng – The SameSite property of Cookie