原文地址：https://alphahinex.github.io/2021/05/30/same-origin-and-same-site-of-cookie/
description: "Cookie 中的同源，等价于同站？！"
date: 2021.05.30 10:34
categories:
- Web
tags: [Web, HTML]
keywords: origin, site, same origin, cross origin, same site, corss site, CSRF, SOP, port, cookie
存储在浏览器中的数据，如 localStorage 和 IndexedDB，是以 源（origin） 进行分割的。每个源都拥有自己单独的存储空间，一个源中的 JavaScript 脚本不能对属于其它源的数据进行读写操作，即所谓的 同源策略（SOP）。
Cookie 的同源
然而 Cookie 在受同源策略约束时，使用不同的源的定义方式。
通常来讲：
同源（Same origin），意味着 scheme/host/port 三元组完全相同。任意一部分不同，即为跨源（cross-origin，或称为跨域）。
而根据 Cookie 的现行标准规范 HTTP State Management Mechanism (rfc6265) ：
- Introduction
...
For historical reasons, cookies contain a number of security and
privacy infelicities. For example, a server can indicate that a
given cookie is intended for "secure" connections, but the Secure
attribute does not provide integrity in the presence of an active
network attacker. Similarly, cookies for a given host are shared
across all the ports on that host, even though the usual "same-origin
policy" used by web browsers isolates content retrieved via different
ports.
即，相同 host，不同端口的服务之间，cookie 是可以共享的！
另外：
8.5. Weak Confidentiality
Cookies do not provide isolation by port. If a cookie is readable by
a service running on one port, the cookie is also readable by a
service running on another port of the same server. If a cookie is
writable by a service on one port, the cookie is also writable by a
service running on another port of the same server. For this reason,
servers SHOULD NOT both run mutually distrusting services on
different ports of the same host and use cookies to store security-
sensitive information.
Cookies do not provide isolation by scheme. Although most commonly
used with the http and https schemes, the cookies for a given host
might also be available to other schemes, such as ftp and gopher.
Although this lack of isolation by scheme is most apparent in non-
HTTP APIs that permit access to cookies (e.g., HTML's document.cookie
API), the lack of isolation by scheme is actually present in
requirements for processing cookies themselves (e.g., consider
retrieving a URI with the gopher scheme via HTTP).
由上可知，Cookie 不提供根据 scheme 和 port 的隔离性，也就是说：
Cookie 中同源的定义，等价于不考虑 scheme 的同站（schemelessly same site）定义!
默认情况下，Cookie 可以在 eTLD + 1 相同的站点间进行共享！
另外，服务端可以通过响应的 Set-Cookie Header，对 Cookie 的可用性进行设定，相关的属性包括 Domain、Path、Secure 等。
比如通过 Path 属性，可以指定允许获得 Cookie 的 URL 路径前缀。
注意：
Path属性意在性能而非安全性。满足同源条件的页面中，依然可以通过document.cookie对 Cookie 进行访问，即使在 path 属性不匹配的情况下。
Cookie 的同站
现行的 rfc6265 标准是 2011 年 4 月开始实行的，在后续的 rfc6265bis 提案的 02 版本中，在 Set-Cookie 的响应头中增加了 SameSite 属性，用来约束对 Cookie 的跨站访问行为，以提升安全性，降低 CSRF 攻击的风险。
该提案的最新版本为 draft-ietf-httpbis-rfc6265bis-07（将于 2021 年 6 月 10 日到期），此版本中 SameSite 属性有三个值：
- Lax：通常情况下不会在跨站请求中携带 Cookie，但用户主动导航至外站时，会携带用户之前访问此外站的 Cookie。在
SameSite属性未被显示设定时，将按照SameSite=Lax进行对携带 Cookie 的约束（07 版提案之前，未设定SameSite等价于SameSite=None）。 - Strict：跨站请求时不会携带 Cookie。
- None：同站和跨站的请求都会携带 Cookie。当设置了
SameSite=None时，Cookie 的Secure属性也必须被同时设定（即此时 Cookie 只能通过 https 协议发送），否则 Cookie 会被拦截。
在此版本提案中，对于同站的定义增加了 scheme 部分，即与最新的 HTML 标准一致：scheme 和 eTLD + 1 同时相同，才能够认为是同站（same site）。
