category
了解为什么需要跨源隔离才能使用强大的功能，如SharedArray Buffer、performance.measureUserAgentSpecificMemory（）和精度更高的高分辨率计时器。
介绍
在使用COOP和COEP使您的网站“跨源隔离”的过程中，我们解释了如何使用COOP和COEP采用“跨源隔离”状态。这是一篇配套文章，解释了为什么需要跨源隔离才能在浏览器上启用强大的功能。
关键词：这篇文章使用了许多听起来相似的术语。为了使事情更清楚，让我们定义它们：
- COEP：跨来源嵌入器策略
- 跨来源开放政策
- CORP：跨来源资源政策
- CORS：跨来源资源共享
- CORB：跨原点读取阻塞
背景
web是基于同源策略构建的：这是一个安全功能，限制文档和脚本如何与来自另一个源的资源交互。这一原则限制了网站访问跨来源资源的方式。例如，来自的文档https://a.example被阻止访问托管在https://b.example的数据.
然而，同源政策在历史上也有一些例外。任何网站都可以：
- 嵌入跨源iframe
- 包括跨来源资源，如图像或脚本
- 使用DOM引用打开跨源弹出窗口
如果网页可以从头开始设计，这些例外情况就不会存在。不幸的是，当网络社区意识到严格的同源政策的关键好处时，网络已经依赖于这些例外情况。
这种松懈的同源政策的安全副作用是通过两种方式弥补的。一种方法是引入一种称为跨来源资源共享（CORS）的新协议，其目的是确保服务器允许与给定来源共享资源。另一种方法是隐式地删除对跨源资源的直接脚本访问，同时保持向后兼容性。这种跨来源的资源被称为“不透明”资源。例如，这就是为什么通过CanvasRenderingContext2D操作跨源图像的像素失败的原因，除非将CORS应用于图像。
所有这些策略决策都发生在浏览上下文组中。
浏览上下文组
很长一段时间以来，CORS和不透明资源的结合足以保证浏览器的安全。有时会发现边缘情况（如JSON漏洞），需要进行修补，但总体而言，不允许直接读取跨源资源的原始字节的原则是成功的。
Spectre改变了这一切，它使加载到与代码相同的浏览上下文组中的任何数据都具有潜在的可读性。通过测量某些操作所花费的时间，攻击者可以猜测CPU缓存的内容，并通过这些内容猜测进程内存的内容。这种定时攻击可能使用平台中存在的低粒度计时器，但可以使用高粒度计时器来加速，包括显式计时器（如performance.now（））和隐式计时器（例如SharedArray Buffers）。如果eviv.com嵌入了一个跨原点图像，他们可以使用Spectre攻击来读取其像素数据，这使得依赖“不透明”的保护无效。
Spectr
理想情况下，所有跨来源请求都应该由拥有资源的服务器明确审查。如果审查不是由拥有资源的服务器提供的，那么数据将永远不会进入邪恶行为者的浏览上下文组，因此将远离网页可能进行的任何Spectre攻击。我们称之为跨起源的隔离的状态。这正是COOP+COEP的意义所在。
在跨源隔离状态下，请求站点被认为不那么危险，这解锁了强大的功能，如SharedArrayBuffer、performance.measureUserAgentSpecificMemory（）和精度更高的高分辨率计时器，否则这些功能可能会被用于类似Spectre的攻击。它还防止修改document.domain。
跨来源嵌入程序策略【Cross Origin Embedder Policy】
跨来源嵌入器策略（COEP）防止文档加载任何未明确授予文档权限的跨来源资源（使用CORP或CORS）。使用此功能，您可以声明文档无法加载此类资源。
COEP的工作原理
若要激活此策略，请将以下HTTP标头附加到文档中：
Cross-Origin-Embedder-Policy: require-corp
require-corp关键字是COEP唯一可接受的值。这强制执行这样的策略，即文档只能加载来自同一来源的资源，或明确标记为可从另一来源加载的资源。
对于可从另一个来源加载的资源，它们需要支持跨来源资源共享（CORS）或跨来源资源策略（CORP）。
跨来源资源共享【Cross Origin Resource Sharing】
如果跨来源资源支持跨来源资源共享（CORS），您可以使用跨来源属性将其加载到您的网页，而不会被COEP阻止。
<img src="https://third-party.example.com/image.jpg" crossorigin>
例如，如果此图像资源使用CORS标头，请使用crossrorigin属性，以便获取资源的请求将使用CORS模式。这也可以防止加载图像，除非它设置了CORS标头。
类似地，您可以通过fetch（）方法获取跨源数据，只要服务器使用正确的HTTP头进行响应，就不需要特殊处理。
跨来源资源政策【Cross Origin Resource Policy】
跨来源资源策略（CORP）最初是作为一种选择加入而引入的，以保护您的资源不被其他来源加载。在COEP的上下文中，CORP可以为谁可以加载资源指定资源所有者的策略。
跨来源资源策略标头采用三个可能的值：
Cross-Origin-Resource-Policy: same-site
标记为同一站点的资源只能从同一站点加载。
Cross-Origin-Resource-Policy: same-origin
标记为同一原点的资源只能从同一原点加载。
Cross-Origin-Resource-Policy: cross-origin
标记为跨来源的资源可以由任何网站加载。（此值与COEP一起添加到CORP规范中。）
注意：一旦添加了COEP头，就无法通过使用服务工作者【service workers】来绕过限制。如果文档由COEP头保护，则在响应进入文档流程之前，或者在响应进入控制文档的服务工作者之前，将遵守该策略。
跨来源开放者政策 【Cross Origin Opener Policy】
跨来源开放者策略（COOP）允许您通过将顶级窗口放在不同的浏览上下文组中来确保它们与其他文档隔离，从而使它们无法直接与顶级窗口交互。例如，如果具有COOP的文档打开一个弹出窗口，其window.opener属性将为null。此外，开启器对它的引用的.closed属性将返回true。
跨来源Opener Policy标头采用三个可能的值：
Cross-Origin-Opener-Policy: same-origin
标记为相同来源的文档可以与同样明确标记为相同起源的相同来源文档共享相同的浏览上下文组。
Cross-Origin-Opener-Policy: same-origin-allow-popups
具有相同来源的允许弹出窗口的顶级文档保留对其任何弹出窗口的引用，这些弹出窗口要么没有设置COOP，要么通过将COOP设置为unsafe none来选择退出隔离。
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none是默认值，允许将文档添加到其打开程序的浏览上下文组中，除非打开程序本身具有相同来源的COOP。
注意：noopener属性的效果与您对COOP的期望相似，只是它只在开场白一侧起作用。（当您的窗口被第三方打开时，您无法解除关联。）当您通过执行window.open（url，'_blank'，'noopener'）或<a target=“_blank”rel=“noopener”>之类的操作连接noopener时，您可以故意将您的窗口与打开的窗口解除关联。虽然noopener可以被COOP取代，但当你想在不支持COOP的浏览器中保护你的网站时，它仍然很有用。
总结
如果您希望有保证地访问SharedArray Buffer、performance.measureUserAgentSpecificMemory（）或精度更高的高分辨率计时器等强大功能，请记住，您的文档需要同时使用值为require corp的COEP和值为同源的COOP。如果两者都不存在，浏览器将无法保证足够的隔离以安全地启用这些强大的功能。您可以通过检查self.crossOriginIsolated是否返回true来确定页面的情况。
在使用COOP和COEP使您的网站“跨源隔离”中了解实现这一点的步骤。
资源
- 登录 发表评论