Use context.initSafeStandardObjects instead of context.initStandardObjects

[faikofhh]

https://github.com/Jaspersoft/jasperreports/blob/895d17ad3fb3bc8cdbb961edaa9a073e110a05d0/jasperreports/src/net/sf/jasperreports/compilers/JavaScriptEvaluatorScope.java#L164

using initStandardObjects allow user to inject code in the report designs in order to load/import undesired Java class into JavaScript execution environment. Please consider fix it.

If initStandardObjects must be used, consider creating a JS Context object that uses ClassShutter to whitelist the safe Java classes.

[dadza]

initSafeStandardObjects would not work given the current way the builtin variables and parameter/field/variable references are implemented. It might be possible to change the JavaScript compiler so that it works with initSafeStandardObjects, we'll consider that for the future.

What we did for now is to make the security mechanism used for Java and Groovy reports - see here - apply to reports with JavaScripts expressions as well. Granting reports the same permissions no matter the report expression language makes perfect sense.

In addition to restricting thinks like file system access, you can use a Java security policy to restrict access to classes in protected packages via the package.access security property. Having a ClassShutter implementation with a class whitelist for JavaScript reports would be an additional security mechanism, we'll consider it.

[ShaheedHaque]

Is there a way to load a Javascript script from the filesystem? Does this block that?

[EDIT] Note that I am currently doing stuff like this in my Javascript expressions:

var x = java.io.RandomAccessFile('/home/.../t.txt', 'r');

and I assuming this change will not affect this.