了解为什么需要跨域隔离才能使用 SharedArrayBuffer
、performance.measureUserAgentSpecificMemory()
和更精确的高分辨率计时器等强大功能。
简介
在将您的网站设置为“跨域隔离”使用 COOP 和 COEP 解释了如何采用 “独立”使用 COOP 和 COEP 处理状态。这是一篇配套文章 为什么需要跨域隔离才能在浏览器中启用强大的功能。
背景
网站建立在同源的基础上
政策:一项安全功能,
文档和脚本如何与来自其他来源的资源进行交互。这个
原则限制了网站访问跨源资源的方式。对于
例如,来自 https://a.example
的文档被禁止访问数据
托管在 https://b.example
上。
不过,同源政策曾出现过一些例外情况。任何网站都可以:
- 嵌入跨源 iframe
- 包含跨源资源,例如图片或脚本
- 使用 DOM 引用打开跨源弹出式窗口
如果网页完全可以从头开始设计,就不会存在这些例外情况。 遗憾的是,当网络社区意识到 严格的同源政策,那么网络原本就已经依赖于这些例外情况。
这种宽松的同源政策的安全副作用已在以下两个部分中进行了修补:
方法。其中一种方式是引入一个名为跨网站转化的新协议
源资源共享 (CORS)
目的是确保服务器允许与
指定来源。另一种方法是隐式取消对脚本的
同时保持向后兼容性。此类
我们把跨源资源称为“不透明”资源。例如,这就是
通过 CanvasRenderingContext2D
操控跨源图片的像素
失败,除非对映像应用了 CORS。
所有这些政策决策都是在浏览上下文组中做出的。
很长时间以来,结合使用 CORS 和不透明资源足以 浏览器的安全性。有时是极端情况(如 JSON 漏洞) 并且需要修补,但总体而言, “允许直接读取跨源资源的原始字节”之前 成功。
这一切都改变了
Spectre:
将任何与您的代码加载到同一浏览上下文组的数据
可能可读。通过测量某些操作所花费的时间,攻击者
就可以猜测 CPU 缓存的内容,通过这些内容,
进程内存。低粒度计时器可能会发生此类计时攻击
但可通过高粒度计时器加快速度,
显式(如 performance.now()
)和隐式(如
SharedArrayBuffer
)。如果 evil.com
嵌入了跨源图片,则可以使用
幽灵攻击读取其像素数据,使保护机制依赖于
“不透明”无效。
理想情况下,所有跨源请求都应由服务器进行明确审查 拥有该资源的权限。如果审查并非由 那么数据就永远不会进入浏览页面 邪恶势力的环境组,因此将远离任何幽灵 网页可进行的攻击。我们称之为跨源隔离状态。 这正是 COOP+COEP 的目的所在。
在跨域隔离状态下,发出请求的网站会被视为不太
危险,则会解锁强大的功能,例如SharedArrayBuffer
、
performance.measureUserAgentSpecificMemory()
和高分辨率
计时器的精确度更高,
可能会用于类似幽灵的攻击。还会禁止修改
document.domain
。
跨源嵌入器政策
跨源嵌入器 政策 (COEP) 可防止出现 文档加载任何未明确授权的跨源资源 文档权限(使用 CORP 或 CORS)。借助此功能,您可以声明 文档无法加载这类资源。
如需激活此政策,请将以下 HTTP 标头附加到文档:
Cross-Origin-Embedder-Policy: require-corp
require-corp
关键字是 COEP 唯一可接受的值。这会强制
指定文档只能从同一来源加载资源,或
明确标记为可从另一来源加载的资源。
若想从其他来源加载资源,这些资源需要支持 跨域资源共享 (CORS) 或跨域资源政策 (CORP)。
跨域资源共享
如果跨源资源支持跨源资源共享
(CORS),那么您可以使用
crossorigin
属性
在不被 COEP 屏蔽的情况下将其加载到您的网页。
<img src="https://third-party.example.com/image.jpg" crossorigin>
例如,如果通过 CORS 标头传送此图片资源,请使用
crossorigin
属性,以便获取资源的请求将使用 CORS
模式。这也
会阻止加载图片,除非设置了 CORS 标头。
同样,您可以通过 fetch()
方法提取跨源数据,
不需要特殊处理,只要服务器以正确的
HTTP
标头。
跨域资源政策
跨域资源政策 (公司) 最初是作为一项可选功能而推出的,目的是防止您的资源 由其他来源加载。在 COEP 上下文中,CORP 可以指定 所有者政策,规定谁可以加载资源。
Cross-Origin-Resource-Policy
标头采用三个可能的值:
Cross-Origin-Resource-Policy: same-site
标记为 same-site
的资源只能从同一网站加载。
Cross-Origin-Resource-Policy: same-origin
标记为 same-origin
的资源只能从同一来源加载。
Cross-Origin-Resource-Policy: cross-origin
任何网站都可以加载标记为 cross-origin
的资源。(
值已添加到
CORP 规格和 COEP。)
跨源打开者政策
跨源打开者政策
(COOP)
通过将顶级窗口放入其他文档
不同的浏览上下文组,这样他们就无法直接与
顶级窗口。例如,如果某个使用 COOP 的文档打开一个弹出式窗口,其
window.opener
属性将为 null
。此外,此 API 的 .closed
属性
opener 对它的引用将返回 true
。
Cross-Origin-Opener-Policy
标头采用三个可能的值:
Cross-Origin-Opener-Policy: same-origin
标记为 same-origin
的文档可以共享相同的浏览上下文
包含同源文档,并且还明确标记为 same-origin
的群组。
Cross-Origin-Opener-Policy: same-origin-allow-popups
包含 same-origin-allow-popups
的顶级文档会保留对
不设置 COOP 或通过
将 COOP 设置为 unsafe-none
。
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none
是默认值,允许将文档添加到其打开者的
浏览上下文组,除非打开程序本身的 COOP 为 same-origin
。
摘要
如果您想确保自己能使用 SharedArrayBuffer
等强大功能,
performance.measureUserAgentSpecificMemory()
或高分辨率
精确程度更高的计时器,只需记住
您的文档需要同时使用值为 require-corp
的 COEP 和
值为 same-origin
的 COOP。如果两者都不存在,浏览器就会
无法保证充分隔离来安全启用这些强大的功能。您
您可通过查看
self.crossOriginIsolated
返回 true
。
如需了解实现此功能的步骤,请参阅将您的网站设为“跨源” “独立”(使用 COOP 和 COEP)。