How do I stop Nashorn from allowing the quit () function?
I am trying to add a scripting function to our system where untrusted users can write simple scripts and execute them on the server side. I am trying to use Nashorn as a scripting engine.
Unfortunately, they've added a few non-standard features for Nashorn:
https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/shell.html#sthref29
Scroll down to Additional Nashorn Built-in Functions and see the quit () function. Yes, if an untrusted user runs this code, the entire JVM is shut down.
This is strange because Nashorn specifically anticipates the execution of untrusted scripts. See: https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html#classfilter_introduction
Applications that embed Nashorn, in particular server-side JavaScript, often have to run scripts from untrusted sources and therefore must restrict access to Java APIs. These applications can implement the ClassFilter interface to restrict Java class access to a subset of Java classes.
Is there a way to prevent this behavior? How can I prevent users from performing any additional functions?
source to share
Unfortunately, there is currently no way to control the creation of custom global functions. One way is to simply remove these functions from the global object after the ScriptEngine is initialized:
final NashornScriptEngineFactory engineManager = new NashornScriptEngineFactory();
final ScriptEngine engine = engineManager.getScriptEngine();
final Bindings bindings = engine.getBindings(ScriptContext.ENGINE_SCOPE);
bindings.remove("print");
bindings.remove("load");
bindings.remove("loadWithNewGlobal");
bindings.remove("exit");
bindings.remove("quit");
System.err.println(engine.eval("'quit is ' + typeof quit"));
If you are using the Nashorn shell this will keep it simple delete quit;
.
If you are using the ScriptEngine interface and create multiple bindings, you will have to do this with every global object / binding you create.
source to share
If you are going to run "untrusted" scripts, run your program with SecurityManager enabled. In doing so, "quit" would result in a SecurityException. ClassFilter itself is not a replacement for the SecurityManager. It is used in conjunction with SecurityManager. Please check the JEP on ClassFilter here: http://openjdk.java.net/jeps/202 . The JEP clearly states the following:
Make security managers redundant for scripting. Application injection must still include security management before evaluating scripts from untrusted sources. Filtering the class alone does not provide a complete sandboxing script. "Even if only untrusted scripts are executed (no additional Java classes), the security manager must be used. Class filtering provides finer control over what the security manager provides. For example, a Nashorn-embedding application can prevent scripting threads or other resource-intensive operations from spawning. which can be resolved by the security manager.
source to share