paulbartrum / jurassic

A .NET library to parse and execute JavaScript code.
MIT License
868 stars 121 forks source link

Block Access to Internet, File System and Shell Commands #191

Closed rafaeltab closed 3 years ago

rafaeltab commented 3 years ago

Hey there,

I am using Jurassic to run code that is made in the browser to allow for more flexible data altering. However, I am worried that if someone gets access to our in-browser code editor they could write malicious scripts and upload them. Jurassic would then execute these script possibly giving them access to our shell or file system.

Is there a way to block Jurassic access to the Internet, File System, and Shell Commands? An example of how I would imagine this would work is:

ScriptEngine engine = new ScriptEngine();
engine.BlockInternetAccess();
engine.BlockFileAccess();
engine.BlockShellAccess()

object result = engine.Evaluate(JsCode);

P.S. Great work on making and maintaining this thing, it is really nice 👍

paulbartrum commented 3 years ago

There is no need to block internet, file or shell access, because Jurassic doesn't include support for any of those things. By default Jurassic only supports the functionality described by ECMAScript 5.1 (with partial support for ECMAScript 6).

If you're allowing malicious scripts I see four potential problems:

For the first problem, you can set a time limit and kill the script if it goes over that limit. For the second and third problems, the only reliable way to mitigate this type of attack (that I know of), is to run the user script in it's own process, since it's generally only possible to limit memory usage at the process level, though doing so is tricky. On Windows you can use something called "job objects" and on Linux you can use "cgroups".

Check out the "Test Suite Runner" project in the Jurassic source code for an example of how to run Jurassic in a separate process (but note this isn't designed to run malicious scripts and doesn't solve all the above problems).

Note: I may add support for dangerous/privileged functionality at a later time (especially support for fetch()), but you'll have to opt-in to it, you won't get it by default.

rafaeltab commented 3 years ago

Hey, thanks for the reply!

This is great to hear, I'll look into the memory and stack problems. I won't be using any .net functionality so that is already good. Keep up the good work 👍

paulbartrum commented 3 years ago

Note that it may be easier/time better spent to properly secure your code editor so unauthorized users can't use it. :-) Up to you though!

Thanks for the complements too, I appreciate it.

rafaeltab commented 3 years ago

np, you deserver it and of course I am trying my best. However, I prefer not to leak all my user's data and compromise the entire server if I make a small mistake

paulbartrum commented 3 years ago

However, I prefer not to leak all my user's data and compromise the entire server if I make a small mistake

Well, fear not, it should not be possible for attackers to do either of those things via Jurassic. The worst an attacker can realistically do is crash the process that is running Jurassic. If you're worried about a server compromise, I recommend you take basic precautions like making sure your web server software + OS are regularly patched and up-to-date, and the server is behind a good firewall. Use two-factor authorization, restrict connections by IP address when possible, that sort of thing.