Cookies are a more common state-keeping option in a wide range of projects. For example, after a user logs in successfully, the server sets the session Id to the current domain through set-cookie. When the front-end invokes the back-end interface, it automatically carries the cookie in the same domain, and then the back-end interface obtains the session Id to verify the validity of the user login status.

Students who have learned about cookies are quite clear that the use of cookies will cause security problems if they are not careful, such as: CSRF (Cross-site Request Forgery), XSSI (Cross site Script Inclusion) attacks, there are many articles on the Internet. To mitigate this risk, Google has developed a security mechanism called Cookie SameSite, which has been used in mainstream browsers for a long time.

What is Cookie SameSite

SameSite is a Cookie property that restricts third-party (cross-domain) Cookie delivery. SameSite has Strict, Lax, and None values to set.

Strict

Strict is the strictest policy. Under Strict, the browser does not allow cookies to be sent from domain A to domain B. Assume that the user has logged in to domain B, and there is A jump link of domain B on A page of domain A. When the user clicks the jump link of domain A to enter domain B, the user does not log in to domain B. This strategy is very secure, but it’s not really a good user experience, so it’s not used very often.

set-cookie: sid=0920770230c103809305605a; samesite=strictCopy the code

Lax

The Lax policy is wider than Strict, and in most cases does not send third-party cookies, but links (), . Assume that the user has logged in to domain B before, and there is A link of domain B on A page of domain A. When you click the jump link of domain A to enter domain B, the login status will still be displayed in domain B. However, if an Ajax POST request is made in domain A to the interface in domain B, the interface will not get the relevant Cookie. Although the Lax policy still carries some risk, it is generally a relatively appropriate choice, so Lax is set as the default for Cookie SameSite in some development languages.

set-cookie: sid=0920770230c103809305605a; samesite=laxCopy the code

None

In practice, there are also some scenarios that need to support cross-domain Cookie transfer (for example, IFrame in domain A is commonly used for embedding links in domain B). In this case, you can choose to set SameSite to None, but there are prerequisites for using None. It requires that the Secure property be set to true, which in turn requires that the B domain be accessed over HTTPS, otherwise it still does not work.

set-cookie: sid=0920770230c103809305605a; secure; samesite=none
Copy the code

Use in.NET Core

The ASP.NET Core Web application is used as an example

var options = new CookieOptions
{
  Expires = DateTime.Now.AddHours(1),
};
_httpContextAccessor.HttpContext.Response.Cookies.Append("sid", "0920770230c103809305605a", options);
Copy the code

While the above code normally does the job of writing cookies, CookieOptions supports additional configurations that can be configured as required. In.net Core 2.2 and.net Core 3.1, the default value of the SameSite attribute for cookies is not the same.

The default value in 2.2 is samesitemode. Lax

The default value in 3.1 has changed to Samesitemode. Unspecified. (This means that the SameSite attribute values are not written, and the browser’s default Cookie policy remains.)

How to solve SameSite problem in IFrame

ASP.NET Core set-cookie. If you want the current domain to be used by iframes of other domains, the basic requirement is that the site must be based on HTTPS, and then modify the code to set the SameSite property to None. Set Secure to true.

var options = new CookieOptions
{
    SameSite = SameSiteMode.None,
    Secure = true
};
Copy the code