Cookies and the Same Site

Posted on 2020-12-18 Edited on 2024-11-19 In Security Waline:

Recently, when reviewing the configuration of cookies, I found a new configuration called sameSite.

The Chinese translation of this sameSite is same site.

Let’s take a look today at what this same site is, what is the difference between it and the same origin, and why cookies clearly have domain and path to specify the scope and need the sameSite attribute.

Same origin and same station

Same origin: Protocol (scheme) + hostname (hostname) + Port Number (port) are exactly the same.
Same site: ‘eTLD + 1’ is exactly the same.

TLD means top-level domain name, such as .com, .org, .cn, etc. However, top-level domain names are not static and will increase over time.

'TLD + 1 'represents a combination of a Top-Level Domain name and the second-level domain name preceding it, for example, the URL is:

1	https://www.example.com:443/foo

So:

‘TLD’ is’ .com ’
TLD+1 是 example.com

However, this representation is flawed, for example for the following URL:

1	https://www.example.com.cn

If according to the above rules, its’ TLD + 1 ‘is’ com.cn ‘, which does not represent this site. What really represents this site should be’ example.com.cn ‘, so the concept of’eTLD’ is derived, that is, ** effective top-level domain name **:

‘eTLD’:’ com.cn ’
eTLD+1：example.com.cn

注意，同源与跨域同级的概念
同站与跨站是相同的概念，比如著名的XSS和CSRF，都是跨站攻击

Scope of cookies

** Cookies have two important attributes: Domain and Path, which indicate the scope of this cookie: **

Domain tells the browser the domain name ownership of the current cookie to be added. If it is not clearly specified, it defaults to the current domain name. For example, the domain name of the cookie added by visiting www.baidu.com defaults to www.baidu.com, and the domain name of the cookie generated by visiting [www.baidu.com is www.baidu.com

Path tells the browser the path attribution of the current cookie to be added, and defaults to the current path if not explicitly specified, such as by visiting www.baidu.com/java/hotspot.html The default path for added cookies is/java/, via www.baidu.com/java/hotspot.html The path of the generated cookie is also /java/

** The cookies submitted by the browser need to meet the following two points: **

Cookies under the current domain name or parent domain name;
Cookies under current path or parent path

CSRF

After understanding the scope of the same site and cookie, let’s take a look at the attack method of CSRF.

Cookies are a solution we use to deal with HTTP statelessness. They achieve the purpose of making HTTP requests carry state by storing some user information in the browser and automatically carrying cookies in subsequent requests.

Cookies are often used to store user identity information. Malicious websites can manage to forge HTTP requests with the correct cookies. This is called a CSRF attack.

For example, when a user logs into the your-bank.com, the bank server sends a cookie.

1	Set-Cookie:id=afasdfafa;

The user later visited the malicious website evil.com, which had a form on it.

1
2
3

<form action="your-bank.com/transfer" method="POST">
  ...
</form>

Once the user is tricked into sending this form, ** since the target of the request is the bank, the content of the cookie in the bank’s domain and path will be automatically carried **, and the bank website will receive the request with the correct cookie. In order to prevent this attack, the form generally has a random token to tell the server that this is a real request.

<form action="your-bank.com/transfer" method="POST">
  <input type="hidden" name="token" value="dad3weg34">
  ...
</form>

This type of cookie guided by a third-party website is called a third-party cookie. In addition to being used for CSRF attacks, it can also be used for user tracking.

For example, Facebook inserts an invisible image on a third-party website.

1	<img src="facebook.com" style="visibility:hidden;">

When the browser loads the above code, it will send a request to Facebook with cookies, so that Facebook will know who you are and what websites you have visited.

SameSite Properties

Starting Chrome 51, browser cookies have added a SameSite property to prevent CSRF attacks and user tracking.

But since cookies already have domain and path, why do you need a sameSite?

** Actually, it’s because sameSite restricts the scope of cookies. The scope restricts what cookies can be obtained when I want to carry cookies in a request. This is called scope, and sameSite restricts whether I allow it to carry cookies if I send a request from my page. **

For example, my own blog page has a link to Taobao, whether this link is posted by myself or injected by XSS, anyway there is such a link, if I click on this link in my blog, Since my blog and Taobao are different stations, the restrictions of sameSite will not allow this request to carry cookies at all. If there is no restriction of sameSite, it will further go to see what cookies are allowed according to the scope.

The’SameSite 'attribute of cookies is used to restrict third-party cookies, thereby reducing security risks.

It can set three values.

Strict
Lax
None

Strict

'Strict 'is the strictest, completely prohibits third-party cookies, and will not send cookies under any circumstances when crossing sites. In other words, ** Cookies will only be brought if the URL of the current webpage matches the request target **.

1	Set-Cookie: CookieName=CookieValue; SameSite=Strict;

This rule is too strict and may result in a very bad User Experience. For example, if the current webpage has a GitHub link, the user will not have GitHub cookies when clicking the jump, and the jump is always not logged in.

Lax

Lax rules are slightly relaxed, and in most cases third-party cookies are not sent, except for Get requests that navigate to the target URL.

1	Set-Cookie: CookieName=CookieValue; SameSite=Lax;

The GET request for navigating to the target URL only includes three cases: link, preload request, and GET form. See the table below for details.

Request Type	Examples	Normal	Lax
Links	‘< a href = “…” >’	Send Cookies	Send Cookies
preload	‘< link rel = “prerender” href = “…”/>’	send cookies	send cookies
GET form	‘< form method = “GET” action = “…” >’	Send Cookies	Send Cookies
POST form	‘< form method = “POST” action = “…” >’	send cookies	do not send
iframe	‘< iframe src = “…” > ’	Send Cookies	Do Not Send
AJAX	'$.get (“…”) ’	Send Cookies	Do Not Send
Image	‘< img src = “…” >’	Send cookies	Do not send

After setting’Strict ‘or’Lax’, CSRF attacks are basically eliminated. Of course, the premise is that the user’s browser supports the SameSite attribute.

None

Chrome plan to make’Lax ‘the default setting. At this time, websites can choose to explicitly turn off the’SameSite’ attribute and set it to’None ‘. However, the premise is that the’Secure’ attribute must also be set (cookies can only be sent over the HTTPS protocol), otherwise it will be invalid.

The following settings are invalid.

1	Set-Cookie: widget_session=abc123; SameSite=None

The following settings are valid.

1	Set-Cookie: widget_session=abc123; SameSite=None; Secure

Reference link:

https://juejin.cn/post/6877496781505200142

https://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html