Running JS code on a server

Edmond Kemokai ekemokai at gmail.com
Mon May 1 13:29:18 UTC 2017


Hi Eli,

This type of sandboxing is indeed a security minefield.

I have had some experience doing this for an embed JS engine (dynjs), you
can see the results here: letzcode.com.

I doubt Nashorn has built-in support for the level of sandboxing you're
looking for...There are a bunch of options such as you mentioned with
limiting access to packages (don't forget getClass() from Java objects
:))...there are also JVM security manager type restrictions that you can
consider.. Some googling may provide additional options such as
containerization for system resource restrictions (CPU, memory, filesystem).

Anyway I can give you my dynjs code modifications if you're interested.

Regards.
Edmond


On May 1, 2017 8:56 AM, "Jim Laskey (Oracle)" <james.laskey at oracle.com>
wrote:

> From: Eliezer Julian <Eliezer.Julian at sapiens.com <mailto:Eliezer.Julian@
> sapiens.com>>
> Subject: Running JS code on a server
> Date: May 1, 2017 at 6:28:05 AM ADT
> To: "nashorn-dev at openjdk.java.net <mailto:nashorn-dev at openjdk.java.net>" <
> nashorn-dev at openjdk.java.net <mailto:nashorn-dev at openjdk.java.net>>
> Cc: Elior Apelbaum <Elior.Apelbaum at sapiens.com <mailto:Elior.Apelbaum@
> sapiens.com>>, Moshe Robinov <Moshe.Robinov at sapiens.com <mailto:
> Moshe.Robinov at sapiens.com>>, Chen Malka <chen.malka at sapiens.com <mailto:
> chen.malka at sapiens.com>>
>
>
> Hi,
>
> I am developing a server side application and would like to add a feature
> that allows a user to submit JS code to be executed via Nashorn. My concern
> is that a user may submit malicious code that may compromise the server. I
> have already limited the script’s access to the bare minimum of Java
> classes, and have implemented a mechanize to kill the script if execution
> time runs over a certain limit. I have also manually removed many of the
> special methods such as print, echo, exit and quit from the Bindings
> object. However, this is extremely limited in scope compared to the damage
> a willfully malicious user may be able to effect via this feature (such as
> allocating too much memory, try to access the file system via the script,
> etc.). I was wondering if the Nashorn development team had any
> recommendations as far as security is concerned, and whether there are any
> plans to add additional security features in the future.
>
> Thanks,
>
> Eli Julian
> Software Developer
> Decision Division
>
> Email: eliezer.julian at sapiens.com <mailto:eliezer.julian at sapiens.com>
> Office: +972-3-7902155
> Mobile: +972-50-3697238
> Skype handle: eli_julian
> Visit us at: www.sapiens.com <http://www.sapiens.com/>


More information about the nashorn-dev mailing list