JS Web 工作者和安全

Question

我想在用户登录后使用专用的 Web Worker（而不是共享 Worker）在后台从 S3 加载文件。为了获得对 s3 文件的访问权限，我需要对用户进行身份验证 (AWS Cognito)。

在创建经过身份验证的 s3 对象后，我尝试像这样从浏览器的 js 调用 Web Worker。

    async function softSyncPlaground(oFoldersInSync, localS3Object){
        var worker = new Worker('js/worker_syncPlayground.js');
         worker.addEventListener('message', function(e) {
            console.log('Worker said: ', e.data);
        }, false);
        worker.postMessage([oFoldersInSync, localS3Object]);
    } 

但它不起作用，因为无法将具有功能的对象提交给网络工作者。

因此，我的后备方案是将凭证发布到 Web Worker 中并在那里生成经过身份验证的 s3 对象。

    async function softSyncPlaground(oFoldersInSync, sIdentityPoolId, oLogins){
        var worker = new Worker('js/worker_syncPlayground.js');
         worker.addEventListener('message', function(e) {
            console.log('Worker said: ', e.data);
        }, false);
        worker.postMessage([oFoldersInSync, sIdentityPoolId, oLogins]);
    }

然而，发送凭证让我在安全方面感到不安。

• “worker.postMessage()”可以被拦截吗？
• 如果我想稍后切换到共享工作人员（我有一个“很好”的用例），这会影响安全性吗？

对这个话题有什么想法吗？

Answer 1

“worker.postMessage()”可以被拦截吗？

是的，就像 JS 中的几乎所有内容一样，但仅限于客户端本身。

例如，我们可以简单地覆盖 Worker 原型的方法，您的实例就会受到影响：

const worker = new Worker( "data:text/javascript," );
worker.postMessage( "my-super-secret-password" );

<script id="evil-script">
Worker.prototype.postMessage = (...args) => {
  console.log("caught", ...args);
};
</script>

但是，如果恶意脚本能够做到这一点，它也能够覆盖您最初用于获取该密码的方法（例如Response.prototype.json或XMLHttpRequest.prototype.response）。
所以这里不存在“附加”风险。

如果我想稍后切换到共享工作人员（我有一个“很好”的用例），这会影响安全性吗？

如果你自己不让事情变得更加危险的话就不会。

The "clients" of a SharedWorker (SW) can only send a MessagePort to the SW, they can't access its global scope and can't read anything from it.
So as long as you don't postMessage() the sensitive information from the SW to the clients yourself, you are safe. Note that since Workers can only be created from same-origin, all clients can actually read its source, but anyway sensitive information should never be hard-coded in JS sources.

^{[gathered from the comments]}
I was worried, as an HTTP Call or a WebSocket would be easier to eavesdrop.

No worries here, the MessagePort interface is 100% client-side. Once again, yes a compromised machine could have a malicious script read directly in its RAM and derive the sensitive information from there, but once again, if they can do it... they can certainly access that token by means a lot simpler.