Sandboxing and security

I'm interested in ClearScript for running untrusted user-provided code for calculations and minor scripting. Of course this leads to various security concerns.

1) Resource Access: opinions on the surface area for accessing resources that the user code should not have access to? For instance, assuming I have added
zero hosted objects, are there any concerns of the user breaking out of V8 into the resources of my process or of the local machine/network?
2) CPU usage: I was able to mock up the ability force a timeout on a script using TPL and ScriptEngine.Interrupt(). However, if V8 supports this natively it would be nice for ClearScript to provide API access to it.
3) Memory usage: Are there any mechanisms available to prevent excessive memory usage by the user code? Is there something in V8 that ClearScript could provide an API to?

If you don't expose any host objects, JavaScript code can only access built-ins such as
Math. However, because it runs within the host's process, it could potentially attack the host by exploiting vulnerabilities in the software and hardware environment. One common technique is the
heap spray.

In ClearScript, V8ScriptEngine's implementation of ScriptEngine.Interrupt() is based on V8's native script interruption mechanism (V8::TerminateExecution()).

Currently ClearScript does not provide a way to limit a script engine's memory usage. This is something we'd like to add in the future. In the meantime, V8 itself is limited by default to approximately 1.4 GB on 64-bit systems, and that limit is lower on
32-bit. Take a look
here.

Thanks for contributing! We've taken a look at your pull request (nice work!), and we're tracking the general feature
here.

At the moment we're wrapping up development of ClearScript 5.2. Once that's done, we'd like to take a little time to investigate a cross-engine approach to memory limit enforcement. Our preference would be to have an engine-agnostic API if possible, but if
not - and this appears likely so far - then we'll incorporate your changes.

Does your statement "If you don't expose any host objects, JavaScript code can only access built-ins such as Math" only apply when using the V8 Engine? It seems like if you use Microsoft.ClearScript.Windows.JScriptEngine for example, you could use
ActiveXObject as an exploit.

Consider this script method, which is designed to let a user write a script to transform data by executing it over each row as the data is copied someplace. The following code executed just fine with the JScript engine, and row.SomeField had the contents of
some-secret-file.txt in it when done.

Does your statement "If you don't expose any host objects, JavaScript code can only access built-ins such as Math" only apply when using the V8 Engine?

​
No, it applies to all supported script engines. ClearScript does not add or remove anything from a script engine at instantiation time. Well, actually, no, that's not 100% true. ClearScript
does create an object named EngineInternal for its own use, but it does not remove any built-ins.
​

It seems like if you use Microsoft.ClearScript.Windows.JScriptEngine for example, you could use ActiveXObject as an exploit.

​
Yes, that's correct. ActiveXObject is a JScript built-in. If that's a concern, you might want to do something like this before running unknown script code: