How do I sandbox user JS without using a VM, transpiler, or whitelist-based API?

Question

I've done my research and there are a few robust ways to sandbox user JS, namely:

• Use a JS VM that runs the JS using a sandboxed form of js, like VM.js
• Use a transpiler like Google Caja, which adds additional checks to preserve certain invariants and disallows specific codepaths
• Use a cross-domain (and/or sandboxed) iframe, potentially with a WebWorker as well, e.g. Jailed

Unfortunately, none of these work well out of the box for my application. I'm trying to build a jsperf.com alternative (i.e. web-based JS benchmarking system), so the first two are out, since they would affect the performance of the user-supplied code, which completely invalidates any benchmarking results.

Jailed is closer, but also not a great alternative because A) its whitelist-only approach is so restrictive that my site would not be able to test the performance of a lot of features of the web (DOM operations, IndexedDb, WebWorkers, LocalStorage, etc.) without a lot of whitelisting that I'm not even sure would work and B) I'm not sure how well maintained (and thus secure) it is given how little activity there is on its GitHub repo.

What is the most permissive system (in terms of closeness to running unsandboxed) that I can safely use to execute user-supplied JS for benchmarking? Is a sandboxed iframe sufficient so the benchmarks can at least access some DOM and other Web APIs? Is the WebWorker really necessary? What do jsfiddle and the like do?

Answer 1

The software engineering definition of a sandbox is an execution environment with specific security constraints maintained. This means that the user JavaScript should not be able to either leverage or impact the JavaScript of the containing web page.

An iframe implementation will neither

• Guarantee that the sandbox code run-time conditions will be the same as if it ran in an independent document nor
• Ensure the parent document will not be impacted and possibly crashed by the sandbox code.

If you have sufficient network and web server control, you can establish fairly secure independence and an authentic execution environment by allowing an authenticated user via HTTPS to provide sand-boxed JavaScript to a completely independent secondary site or sites. Use of sub-domains can reduce the cost of this approach. You may have to use the target='_blank' hack that some consider a violation of the www model.

To be careful not to create security holes with this arrangement, there are a few recommendations.

• Use a server-side include that precisely acquires the sandbox code.
• Carefully tighten all web server directory access.
• Validate the syntax of the JavaScript.