5

I have an untrusted code submitted by a user, and I need to execute it in a sandboxed environment in a browser.

I was advised that Web-Workers cannot be secure enough for that, and that a sandbxed iframe should better be used. This page:

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Web_Workers

also says workers are not suitable for untrusted code.

But if I create a worker from a Blob, its url even has a different protocol (blob://). Is separate origin policy applied to the worker code in this case?

If there are additional reasons, why a worker is (by default) less restricted comparing to the sandboxed iframe (accesing IndexedDB or something else), is there any chance to set-up a worker somehow so that it would be restricted enough, or should I still use sandboxed iframe anyway?

asvd
  • 944
  • 10
  • 16

1 Answers1

8

Is separate origin policy applied to the worker code in this case?

No, from the current editor's draft of the File API specification:

The origin of a Blob URL must be the same as the effective script origin specified by the incumbent settings object at the time the method that created it -- either URL.createObjectURL or URL.createFor -- was called.

additional reasons, why a worker is (by default) less restricted comparing to the sandboxed iframe

Sandboxed iframes can specify some permissions on things other than cross-origin communication. For example, you can prevent the sandboxed content from opening popups. Although web workers currently don't have APIs to do many of these things.

is there any chance to set-up a worker somehow so that it would be restricted enough

There just isn't any security mechanism for web workers. There are other tools in the web platform for isolating untrusted code, like a sandboxed iframe as you point out. You could have a sandboxed iframe create a web worker, if that's any better.

guest
  • 6,450
  • 30
  • 44
  • In the time since this question was asked and answered, WebAssembly has emerged as a viable option to sandbox third-party code. It doesn't have access to any of the browser's APIs. Although that's set to change at some point, making wasm a first-class citizen of the browser, a sandboxed option is likely to remain for backwards compatibility. – Steve Jun 02 '21 at 01:24