关于网络安全:讲清楚同源跨源同站跨站

本文首发国内开源代码托管平台Gitee
文章地址：
https://gitee.com/gooder4j/co…
仓库会集英语meme公众号【Yopen】和技术公众号【鹏哥儿的Echo】相干文章
感觉不错的话，你的star是对我最大的反对！

鹏哥儿最近从新回顾了一下XSS（Cross Site Script）和CSRF（Cross Site Request Forgery），又分割到cookie的同源策略（Same-origin policy），发现自己对源（origin）和站（site）有些混同，所以找了篇优良的文章：Understanding “same-site” and “same-origin”，来对两者加以辨别。

源

“Origin” is a combination of a scheme (also known as the protocol, for example HTTP or HTTPS), hostname, and port (if specified). For example, given a URL of https://www.example.com:443/foo , the “origin” is https://www.example.com:443.

“源”是scheme（也被称为协定，例如HTTP和HTTPS），主机域名和端口（如果有指定）的联合。例如，给定一个URLhttps://www.example.com:443/foo，它的“源”是https://www.example.com:443。

一条申请的外围局部就是这三局部：scheme+主机域名+端口，三者可能惟一标识通信方，这三局部的组成也被称为套接字（socket）。

下文scheme通通指例如HTTP或者HTTPS这样的协定。

同源和跨源

Websites that have the combination of the same scheme, hostname, and port are considered “same-origin”. Everything else is considered “cross-origin”.

雷同scheme、主机域名和端口联合的网站被认为是“同源”，其余的被认为是“跨源”。

同源是最严格的，scheme、主机域名和端口必须都要雷同。

假如当初有源A：https://www.example.com:443

大家能够遮住第2列，猜一猜源B和源A是属于同源还是跨源：

站

Top-level domains (TLDs) such as .com and .org are listed in the Root Zone Database. In the example above, “site” is the combination of the TLD and the part of the domain just before it. For example, given a URL of https://www.example.com:443/foo , the “site” is example.com.

根域服务器列出了例如.com和.org这样的顶级域名（Top-level domain，简称TLD）。在下面这个例子中，站就是顶级域名TLD加上它之前的局部域名。例如，给定一个URL是 https://www.example.com:443/foo，那么它的“站”就是example.com。

站其实就是主机域名的限定子集：局部域名+顶级域名。

想要理解一个域名是不是顶级域名，能够到这个网址去查看：https://www.iana.org/domains/…

However, for domains such as .co.jp or .github.io, just using the TLD of .jp or .io is not granular enough to identify the “site”. And there is no way to algorithmically determine the level of registrable domains for a particular TLD. That’s why a list of “effective TLDs”(eTLDs) was created. These are defined in the Public Suffix List. The list of eTLDs is maintained at publicsuffix.org/list.

然鹅，对于例如.con.jp或者.github.io，仅应用.jp和.io这样的顶级域名TLD来说，没方法准确标识一个“站”。并且对于一个特定的顶级域名TLD，这里也没有算法去确定可注册域名的等级。这就是为什么一系列“无效顶级域名（effective TLD，简称eTLD）”被创立进去。

域名也是分无效有效的，不过，个别记住个.com就行了，其余的去这个网站查一下就行了：https://publicsuffix.org/list/

The whole site name is known as the eTLD+1. For example, given a URL of https://my-project.github.io , the eTLD is .github.io and the eTLD+1 is my-project.github.io, which is considered a “site”. In other words, the eTLD+1 is the effective TLD and the part of the domain just before it.

整个站名被称为“eTLD+1”，例如，给定一个URL：https://my-project.github.io，eTLD是.github.io，eTLD+1是my-project.github.io，eTLD被认为是一个“站”。换句话说，eTLD+1是无效的TLD加上它之前的局部域名。

假如当初有源A：https://www.example.com:443

大家同样能够遮住第2列，猜一猜源B和源A是属于同站还是跨站：

相比于同源，同站显得雷同更加宽容。

同协定同站

The definition of “same-site” is evolving to consider the URL scheme as part of the site in order to prevent HTTP being used as a weak channel. As browsers move to this interpretation you may see references to “scheme-less same-site” when referring to the older definition and “schemeful same-site” referring to the stricter definition. In that case, http://www.example.com and https://www.example.com are considered cross-site because the schemes don’t match.

“同站”的定义逐步倒退，思考把URL的scheme纳为站的一部分，用于避免HTTP被作为弱隧道。当浏览器转向这种解释时，对于“scheme-less same-site”（不同协定同站）指向旧的定义，“schemeful same-site”（同协定同站）指向更严格的定义。在这样的例子中， http://www.example.com 和 https://www.example.com被认为是跨站的，因为它们之间的scheme是不匹配的。

同协定同站也就是scheme+(eTLD+1)，就能够认为他们同站。为什么要思考scheme呢，文中提到HTTP被利用做弱隧道，其实也就是说攻击者会利用不平安的http发动CSRF攻打一个https平安站点^[2]^。

假如当初有源A：https://www.example.com:443

如何查看一个申请是“同站”，“同源”，或者“跨站”

Chrome sends requests along with a Sec-Fetch-Site HTTP header. No other browsers support Sec-Fetch-Site as of April 2020. This is part of a larger Fetch Metadata Request Headers proposal. The header will have one of the following values:

• cross-site
• same-site
• same-origin
• none

Chrome发送随同Sec-Fetch-SiteHTTP申请头的申请。其余浏览器截至2020年4月还没有反对Sec-Fetch-Site。这是获取元数据申请头 提案更广的一部分。这个头部会有一个如下其中之一的值：

• cross-site
• same-site
• same-origin
• none

在chrome上输出一个网址：https://juejin.cn/post/705343…，F1轻易查看一条申请，在申请头上的确是能够看到这个sec-fetch-site。（没有chrome的小伙伴也能够用Edge浏览器:man_technologist:）

By examining the value of Sec-Fetch-Site, you can determine if the request is “same-site“, “same-origin“, or “cross-site” (“schemeful-same-site” is not captured in Sec-Fetch-Site).

通过查看Sec-Fetch-Site的值，你能够确定一个申请是否是“same-site”，“same-origin”，或者“cross-site”（“schemeful-same-site”不能被“Sec-Fetch-Site”捕捉）。

总结

源看三局部：

1. scheme
2. 主机域名
3. 端口

站看两局部

1. scheme
2. 局部域名+无效顶级域名

REFERENCE

[1] https://web.dev/same-site-sam…,considered%20%22cross%2Dorigin%22.

[2] https://datatracker.ietf.org/…