Securing Javascript execution

[hvbtup]

BIRT reports support Javascript, implemented with Rhino.
But Rhino is not just a JS implementation, it allows to interact with the Java VM.

Consequently, a BIRT report can use practically any Java class.
This is fine, because it makes BIRT very flexible.

A BIRT report can do everything that the Java process running BIRT is allowed to do by the OS.

But a BIRT report might be programmed in an unsecure way, or it may contain malicious code.

So, to prevent attacks, all the reports must come from a trusted source.

For a human reader and for security software, it is very hard to see what a BIRT report actually does by just looking at the rptdesign file,
because it is an XML file which can only be understood with the help of the BIRT designer.

So it is really a question of trust, you cannot examine a report with reasonable effort to see if it contains unsecure code or malicious code.

The Rhino engine supports a gatekeeper, which can prevent access to Java classes based on the package and class name, using a "ClassShutter" class and overwriting the "getClass" method, see https://codesent.io/blog/code-sentinels-1/discovering-rhinos-blind-spot-1

So, we could prevent access to e.g. java.io.File or to the java.io package etc from Javascript in reports using this approach.

However, many reports need access to certain Java packages and classes.

So there is probably not a simple solution using something like a central allow/deny list.
Instead it should be configurable based on the report module name.

I tihnk that the details of such a gatekeeper would be implementation specific anyway,
so I think this configuration cannot be just built in into BIRT.

But it would be nice if BIRT would support a simple gatekeeper with a central deny/allow repository backed by a configuration file as a default, together with the ability to use an alternative gatekeeper implementation.

[speckyspooky]

I like the idea of the gatekeeper. If we would implement such gatekeeper the configuration has to be availble not only via overwrite of implementations.
The requirement would be that a configuration according to the viewer.properties is available so that the engine can controlled via cetntral standard configuration to avaoid implementation efforts.
Many implementations integrate BIRT in a raw way and they would nee this way of configuration.
This would be a familiar way according to the module-opening of the JVM to load external resources directly.