Add a wiki page showing how to apply a timeout to script execution about jurassic HOT 6 CLOSED

Clearly people are interested in this type of sandboxing functionality! I've added your wiki page. I'm not completely convinced that it's possible to robustly sandbox hostile code using threads -- I would advocate for using child processes and IPC instead. Stack overflow and out of memory exceptions are particularly hard to recover from. Sadly, creating child processes is inconvenient and not supported in all .NET environments (e.g. universal apps), so I get why people want to use threads.

from jurassic.

Well, for now i've switched from js to SPRAK language ( https://github.com/eriksvedang/Sprak ) , because its original interpreter has 100% controlled exectuion environment - instead of just running it you can call Start(), then Step() and do as many steps through the script as you want to before calling thread sleep. that helps immensely.

from jurassic.

@paulbartrum Great, thanks!
I see that the wiki is publicly editable, is it OK if I edit the page? E.g. make it clearer that the helper allows to run the Javascript on the same Thread instead of using a new one. I also saw that you merged the push request about limiting recursion depth, so I could add that to the page.

About sandboxing functionality, I agree that these two features are not enough (also the recursion limit might not save you if a script function generates a IL method that has lot of variables in the stack).
Another problem is (as you already said in one of the issues) that the script can still allocate arbirary amounts of memory, e.g. with

var s = 'a';
for (;;) s += s;

However, for example Firefox also runs scripts from untrusted sources in the same process where the GUI etc. runs. When Firefox runs a script with an infinite loop, the GUI will hang for some seconds, but then the user has the choice to abort the script (this similar to set a timeout as described in the wiki article). If the script runs an endless recursion, the script will receive a "too much recursion" InternalError, or if it allocates to much memory, it will receive an "allocation size overflow" InternalError (but the process continues to run in either case).

It probably is not easy to handle the case of too much allocated memory, as I assume Jurassic simply relies on the .NET GC to reclaim unreferenced JavaScript objects and e.g. uses native .Net Strings etc.
One thing that I have thought of is if the Script Engine counts each allocated entry for datatypes that can grow, e.g. a String (where for one String a new, longer String can be created) and ObjectInstances (where properties can be added), so that one could specify a maximum string length (cumulated string length of all strings that are returned or concatenated) or object key count (even without using WeakReferences to track if objects were collected by GC). However I guess that would have a huge impact on performance (so if anything, it would have to be enabled at compile time).

Thanks!

from jurassic.

Hi,
sorry to write again, but would it be OK if I edit the Wiki page (Safely executing user provided scripts)? I have updated the forked wiki page (added notes about limiting recursion depth and improved description for the helper class), and would like to update the Jurassic wiki page.
Thanks!

from jurassic.

I added you as a collaborator, but then I realised that anyone can edit the wiki, collaborator or no... ha. Go ahead and make the change.

from jurassic.

Cool, thank you! I have update the wiki page. (AFAIK, by default a wiki on Github is publicly editable, but this can be changed in the repo settings).

For reference, the Wiki page URL is: https://github.com/paulbartrum/jurassic/wiki/Safely-executing-user-provided-scripts

from jurassic.