Distributive-Network / PythonMonkey

A Mozilla SpiderMonkey JavaScript engine embedded into the Python VM, using the Python engine to provide the JS host environment.
https://pythonmonkey.io
Other
855 stars 40 forks source link

Sandboxing evaluated JavaScript code #207

Open mashdragon opened 11 months ago

mashdragon commented 11 months ago

Describe your feature request here.

I would like to run "somewhat untrusted" JavaScript code in PythonMonkey in a sandbox with restrictions on what it is allowed to do. For example, I would like to run code which should not be able to:

Is this something that could possibly be done? I assume such options would go in the evalOpts argument of eval (documentation of the evalOpts argument would be helpful to have).

Currently I am using this crude approach that just deletes the objects from the globalThis object, but I do not know if it is secure in any way:

for key in ['python', 'bootstrap', 'pmEval', 'XMLHttpRequestEventTarget', 'XMLHttpRequestUpload', 'XMLHttpRequest']:
  del pm.globalThis[key]

Code example

No response

wiwichips commented 11 months ago

Hi @mashdragon , this is a really cool feature request - but probably outside the scope of PythonMonkey.

Interestingly, our main product at Distributive is a distributed compute platform which utilizes edge computing to execute JavaScript / WebAssembly in parallel. Anyone can contribute their compute to our network by running a worker (https://dcp.work/)

In order to do this we have to evaluate JavaScript code within a sandbox https://github.com/Distributed-Compute-Labs/dcp-client/tree/release/libexec/sandbox - you might find that code interesting or relevant

Xmader commented 6 months ago

Might be solved by https://github.com/Distributive-Network/PythonMonkey/issues/208

wesgarland commented 4 months ago

I won't stake my life on it, but removing everything from the global object is PROBABLY okay for what you're after, as that is how we "give" capabilities to JS in the first place.

Where this might prove vulnerable is attacks on the python engine, accessing it either by walking the prototype chain of supplied methods (eg setTimeout, console.log) or Python type wrappers. Securing Python is completely out of scope for us.