使用限制属性安全地进行弹出式交互

跨域打开者政策 (COOP) 的新值可用:restrict-properties。它带来安全优势,可让您更轻松地采用跨域隔离,同时可让您的网站与第三方弹出式窗口交互,以实现付款、身份验证或其他用例。

若要使用 restrict-properties 进行实验,请从 Chrome 116 开始参与源试用

restrict-properties 有两个主要用例:

默认情况下,任何网站都可以在弹出式窗口中打开您的应用,并获取对该应用的引用。

恶意网站可利用这一点执行跨网站泄露等攻击。为了降低此风险,您可以使用 Cross-Origin-Opener-Policy (COOP) 标头。

到目前为止,您的“Cross-Origin-Opener-Policy”选项受到限制。您可以执行以下任一操作:

  • 设置 same-origin,,用于阻止与弹出式窗口的所有跨域互动。
  • 设置 same-origin-allow-popups,用于阻止在弹出式窗口中打开您网站的所有跨源互动。
  • 设置 unsafe-none,以允许与弹出式窗口进行所有跨源互动。

这使得需要在弹出式窗口中打开的网站无法与其启动方式进行交互以强制执行 COOP。这使得单点登录和付款等关键用例无法避免跨网站泄露。

Cross-Origin-Opener-Policy: restrict-properties 可解决此问题。

使用 restrict-properties 时,可用于帧计数和其他跨站泄露攻击的属性不可用,但允许通过 postMessage 和 closed 在窗口之间进行基本通信。

这样可以在维护关键用例的同时提高网站的安全性。例如:

  • 如果您在弹出式窗口中提供服务,设置 Cross-Origin-Opener-Policy: restrict-properties 可以保护自己免受一系列跨网站泄露攻击。 您仍然可以打开之前可以打开的所有页面。
  • 如果您需要访问跨源弹出式窗口,可以设置 Cross-Origin-Opener-Policy: restrict-properties,从而保护您的网站免受 iframe 计数的影响。今天打开的那组弹出式窗口将保持不变。
  • 如果 opener 和 openee 均设置了标头,并且页面是跨源页面,则其行为类似于其中一个设置了标头。如果它们同源,则授予完整访问权限。

某些 Web API 会增加出现旁路攻击(例如 Spectre)的风险。为了降低这种风险,浏览器提供了一种基于选择启用的隔离环境,称为跨域隔离。在跨域隔离状态下,网页可以使用特权功能,包括 SharedArrayBufferperformance.measureUserAgentSpecificMemory() 和分辨率更高的高精度计时器,同时将源站与其他源隔离开(除非它们选择启用)。

到目前为止,若要使用这些 API,您必须设置 Cross-Origin-Opener-Policy: same-origin。但是,这会破坏您可能需要的任何跨源弹出式流程,例如单点登录和付款。

现在可以使用 Cross-Origin-Opener-Policy: restrict-properties(而非 Cross-Origin-Opener-Policy: same-origin)启用跨域隔离。它不会断开开放式关系,而仅仅将其限制为 window.postMessage() 和 window.closed 的最小通信子集。

您可以通过以下两个标头启用跨域隔离:

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: require-corp

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: credentialless

如需详细了解 credentialless,请参阅使用 COEP: credentialless 加载不含 CORP 标头的跨源资源

您可以观看此跨域隔离演示,试用各种标头选项。

如需使用 Cross-Origin-Opener-Policy: restrict-properties 进行实验,请选择加入源试用

目前只有 Chrome 支持 Cross-Origin-Opener-Policy: restrict-properties。其他浏览器正在积极参与标准化的讨论

同时在弹出式窗口和主页上设置 COOP: restrict-properties 不会导致限制。如果仅在弹出式窗口或主页面上设置此政策,系统将禁止通过 opener 访问除 postMessage 和 closed 以外的属性,即使这两个项目同源也是如此。

根据到目前为止的反馈,我们怀疑 window.postMessage 和 window.closed 足以满足大多数工作流的需求,但我们仍在考虑将其开放给其他属性。如果您有仅使用 postMessage 和 closed 无法解决的用例,请在“intent to Experiment”线程中提供反馈。

阅读余下内容
 

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注


京ICP备12002735号