为什么需要“跨源隔离”来实现强大的功能

了解为什么需要跨域隔离才能使用 SharedArrayBufferperformance.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 的目的所在。

在跨域隔离状态下,发出请求的网站会被视为不太 危险,则会解锁强大的功能,例如SharedArrayBufferperformance.measureUserAgentSpecificMemory()高分辨率 计时器的精确度更高, 可能会用于类似幽灵的攻击。还会禁止修改 document.domain

跨源嵌入器政策

跨源嵌入器 政策 (COEP) 可防止出现 文档加载任何未明确授权的跨源资源 文档权限(使用 CORP 或 CORS)。借助此功能,您可以声明 文档无法加载这类资源。

COEP 的运作方式

如需激活此政策,请将以下 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

COOP

Cross-Origin-Opener-Policy 标头采用三个可能的值:

Cross-Origin-Opener-Policy: same-origin

标记为 same-origin 的文档可以共享相同的浏览上下文 包含同源文档,并且还明确标记为 same-origin 的群组。

COOP

Cross-Origin-Opener-Policy: same-origin-allow-popups

包含 same-origin-allow-popups 的顶级文档会保留对 不设置 COOP 或通过 将 COOP 设置为 unsafe-none

COOP

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)

资源