Iframe中的SharedArrayBuffer

Question

因此，SharedArrayBuffer最近将仅限于跨原点的隔离页面作为一种安全修补程序。

我们有一个依赖于SharedArrayBuffer的工具，我通过将它移到去掉所有其他站点UI和其他站点UI的最基本的页面，并发送以下标题来重新工作它：

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

尝试将它加载到一个功能齐全的站点的iframe中，会给我控制台错误SharedArrayBuffer will require cross-origin isolation as of M92和ReferenceError: SharedArrayBuffer is not defined --就像我在交叉原点之前一样，将工具隔离在最小页面上。

我想要包含iframe的页面并不是跨源隔离的。这样做是非常困难的，如果不是不可能的话。我根本不需要从父页面和iframe交谈，这只是一个方便/风格的东西。目前生产上的解决方案只是将用户链接到新窗口中最小的跨源工具页面，但这是相当尴尬的。

我所希望的是，有一些组合的iframe 沙箱属性或什么东西，将使这一工作？我和这个吵了几个小时。

就我所知，这可能是不可行的。

Answer 1

我不确定在您的情况下，这个选项是否是一个解决方案，但也许它可以帮助您找到一个完整的解决方案。此博客描述了通过在ServiceWorker中修改头来启用SharedArrayBuffer。它的工作顺序如下：

1. 第一次加载页面时，将注册服务工作人员
2. 页面被重新加载。
3. SharedArrayBuffer变得可用，因为ServiceWorker控制所有请求的所有CORS头。

服务工作者通过添加CORS/COEP头来修改所有请求(示例摘自上述blogpost)：

​

self.addEventListener("install", function() {
  self.skipWaiting();
});

self.addEventListener("activate", (event) => {
  event.waitUntil(self.clients.claim());
});

self.addEventListener("fetch", function(event) {
  if (event.request.cache === "only-if-cached" && event.request.mode !== "same-origin") {
    return;
  }

  event.respondWith(
    fetch(event.request)
    .then(function(response) {
      // It seems like we only need to set the headers for index.html
      // If you want to be on the safe side, comment this out
      // if (!response.url.includes("index.html")) return response;

      const newHeaders = new Headers(response.headers);
      newHeaders.set("Cross-Origin-Embedder-Policy", "require-corp");
      newHeaders.set("Cross-Origin-Opener-Policy", "same-origin");

      const moddedResponse = new Response(response.body, {
        status: response.status,
        statusText: response.statusText,
        headers: newHeaders,
      });

      return moddedResponse;
    })
    .catch(function(e) {
      console.error(e);
    })
  );
});

​

Answer 2

尝试在iframe的allow-scripts属性中添加allow-same-origin和allow-same-origin令牌：

<iframe src="…" sandbox="allow-scripts allow-same-origin"></iframe>
                         ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^

以下是有关这一主题的一些相关资源：

• 沙箱，IFrame，和允许-相同来源 (StackOverflow问题)
• 通过sandbox属性保护iframe
• *内联框架元素 (MDN )，-不要错过属性描述中关于安全性的Note。

首先尝试上面的内容，如果它没有帮助您解决SharedArrayBuffer问题，那么事情就会变得更复杂一些。

正确的跨源需要来自子资源的显式头( <iframe>必须发送标头)，当子资源是第三方且失控时，这是一个大问题。为了缓解这个问题，有一个Cross-Origin-Embedder-Policy: credentialles。

然而，有一个陷阱：作品 (糟糕，这正是我们所需要的！)有关于匿名iframes的讨论，可以解决这个问题，但它还没有解决，所以我不会在这里屏住呼吸。

因此，剩下的唯一选择是延迟铬行为的这一改变 (这可以在Chrome 103之前完成)：

1. 请求一个令牌是你的本源。
2. 将令牌添加到页面中。有两种方法可以这样做：
   • 在每个页面的头部添加一个<meta>标记。例如，这可能类似于：<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
   • 如果可以配置服务器，还可以使用Origin-Trial header添加令牌。生成的响应头应该类似于：Origin-Trial: TOKEN_GOES_HERE