javascript - JS Web workers and security - Stack Overflow

admin管理员组

文章数量:1426220

I want to use a dedicated web worker (not a shared worker) to load files from S3 in the background after users login. To gain access to the s3 files, I need to authenticate the user (AWS Cognito).

I tried calling the web worker from the browsers' js like this, after creating an authenticated s3 object.

    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]);
    } 

But it won't work as one can't submit an object with functions into a web worker.

So my fallback is to post the credentials into the web worker and generate the authenticated s3 object there.

    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]);
    }

However, sending credentials around makes me feel uneasy in terms of security.

• Can "worker.postMessage()" be intercepted?
• If I want switch to a shared worker, later on (I've a "nice to have" use case for this), would this affect security?

Any thoughts on this topic?

I want to use a dedicated web worker (not a shared worker) to load files from S3 in the background after users login. To gain access to the s3 files, I need to authenticate the user (AWS Cognito).

I tried calling the web worker from the browsers' js like this, after creating an authenticated s3 object.

    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]);
    } 

But it won't work as one can't submit an object with functions into a web worker.

So my fallback is to post the credentials into the web worker and generate the authenticated s3 object there.

    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]);
    }

However, sending credentials around makes me feel uneasy in terms of security.

• Can "worker.postMessage()" be intercepted?
• If I want switch to a shared worker, later on (I've a "nice to have" use case for this), would this affect security?

Any thoughts on this topic?

• javascript
• amazon-web-services
• security
• amazon-s3
• web-worker

Share Improve this question Follow edited Apr 15, 2021 at 11:50 HOK asked Apr 15, 2021 at 10:07 HOKHOK 26722 silver badges1414 bronze badges 4

• 1 I'm not an expert in this area and with my rep people tend to give my views more weight than they deserve, so I'll post this as a ment rather than answer: "Can "worker.postMessage()" be intercepted?" Anything on the client can be intercepted...on the client. The postMessage call is entirely within the browser's JavaScript environment(s). If you have the credentials in your main thread, you already have them in the browser's JavaScript environments. So it's not less secure to send that information to the worker thread. If the JavaScript environment is promised, it's promised. – T.J. Crowder Commented Apr 15, 2021 at 10:14
• ... "If I want switch to a shared worker, later on...would this affect security?" Shared workers are only shared within an origin (same protocol, host and port). They aren't accessible from outside your origin. That doesn't seem (to me) to be a significant security issue. – T.J. Crowder Commented Apr 15, 2021 at 10:14
• Thanks for the ment @T.J.Crowder - it's reassuring. I understand and know about the "promised client" thing. I was not sure how the message worked. As you seem pretty confident it's a JavaScript engine internal message, I take that for granted. I was worried, as an HTTP Call or a WebSocket would be easier to eavesdrop. But if that's not used by postMessage() my solutions seams fair enough for my application. – HOK Commented Apr 15, 2021 at 11:32
• It's not internal to JavaScript, but to the browser. (Sorry, I gave the wrong impression above.) Specifically, postMessage is a browser API called from JavaScript that then goes through the browser's internals and ends up triggering an event in JavaScript again at the other end. But it's all internal to the browser. Happy coding! – T.J. Crowder Commented Apr 15, 2021 at 11:42

Add a ment  | 

1 Answer 1

Sorted by: Reset to default 7

Can "worker.postMessage()" be intercepted?

Yes, just like pretty much everything in JS, but only from the client-side itself.

For instance, one could simply overwrite the Worker's prototype's method and your instance would get affected:

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>

But if a malicious script is able to do that, it is also able to overwrite the methods you used to get that password in the first place (e.g Response.prototype.json or XMLHttpRequest.prototype.response).
So there is no "added" risk here.

If I want switch to a shared worker, later on (I've a "nice to have" use case for this), would this affect security?

Not if you don't make it more dangerous yourself.

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 ments]}
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 promised 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.

本文标签： javascriptJS Web workers and securityStack Overflow