PythonMonkey icon indicating copy to clipboard operation
PythonMonkey copied to clipboard

Sandboxing evaluated JavaScript code

Open mashdragon opened this issue 2 years ago • 5 comments

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:

  • Access the this.python object
  • Make network requests via XMLHttpRequest or fetch
  • Do anything with the bootstrap object, such as making local file requests

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

mashdragon avatar Dec 30 '23 06:12 mashdragon

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

wiwichips avatar Jan 05 '24 17:01 wiwichips

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

Xmader avatar May 08 '24 21:05 Xmader

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.

wesgarland avatar Jul 19 '24 11:07 wesgarland