On letzcode.com open up a JavaScript window and type:
var t =0;
while (true){
t++;
}
Your window will lock for a bit while the loop runs but then stops... If
you then type t you'll see the value of the count...this shows that the
loop ran but was interrupted... Basically I had to modify the interpreter
to look for loops and time them per request...Nashorn is a general purpose
application platform so this sort of very customized sandboxing is not
likely to be easily supported.
Again my offer stands if you're interest.
-Edmond
On May 1, 2017 12:20 PM, "Eliezer Julian" <eliezer.jul...@sapiens.com>
wrote:
> How, thanks for the suggestions. Like I wrote in my original post I have
> already limited class access. My concern now is something like an endless
> loop or extreme memory allocation which can tie up resources of the server
>
> ________________________________
> From: G W <grwon...@gmail.com>
> Sent: Monday, May 1, 2017 6:18:02 PM
> To: Eliezer Julian
> Cc: nashorn-dev@openjdk.java.net; Chen Malka; Elior Apelbaum; Moshe
> Robinov
> Subject: Re: Running JS code on a server
>
> Eli,
> Have you tried implementing jdk.nashorn.api.scripting.ClassFilter to
> limit Class access. Also for resource access, you need to to create
> wrappers.
> e.g. for File access:
> function File(f){
> this.file = f;
> this.delete = function(){
> org.sprnkl.server.js.SprnklFile.delete(jsrequestobj,this.file);
> return this;
> }
> this.create = function(dr){
> org.sprnkl.server.js.SprnklFile.create(jsrequestobj,this.file);
> return this;
> }
> this.read = function(){
> return org.sprnkl.server.js.SprnklFile.read(jsrequestobj,this.file);
> }
> this.exists = function(){
> return org.sprnkl.server.js.SprnklFile.exists(jsrequestobj,this.file);
> }
> this.length = function(){
> return Math.round(org.sprnkl.server.js.SprnklFile.length(
> jsrequestobj,this.file));
> }
> this.list = function(){
> return org.sprnkl.server.js.SprnklFile.list(jsrequestobj,this.file);
> }
> this.isDirectory = function(){
> return org.sprnkl.server.js.SprnklFile.isDirectory(
> jsrequestobj,this.file);
> }
> this.readString = function(){
> var rb = this.read();
> var rb2 = [];
> for (var ct = 0;ct < rb.length;ct++){
> rb2.push(rb[ct]);
> }
> return String.fromCharCode.apply(String, rb2);
> }
> this.write = function(b,dr){
> if (dr == undefined) dr = true;
>
> org.sprnkl.server.js.SprnklFile.write(jsrequestobj,this.file,b,dr);
> return this;
> }
> this.writeString = function(s,dr){
> return this.write(s.getBytes(),dr);
> }
> }
>
> I have a Framework that is a work in process. Would be happy to share the
> code if interested.
> Regards
>
> On Mon, May 1, 2017 at 8:55 AM, Jim Laskey (Oracle) <
> james.las...@oracle.com<mailto:james.las...@oracle.com>> wrote:
> From: Eliezer Julian <eliezer.jul...@sapiens.com<mailto:
> eliezer.jul...@sapiens.com> <mailto:eliezer.jul...@sapiens.com<mailto:
> eliezer.jul...@sapiens.com>>>
> Subject: Running JS code on a server
> Date: May 1, 2017 at 6:28:05 AM ADT
> To: "nashorn-dev@openjdk.java.net<mailto:nashorn-dev@openjdk.java.net>
> <mailto:nashorn-dev@openjdk.java.net<mailto:nashorn-dev@openjdk.java.net>>"
> <nashorn-dev@openjdk.java.net<mailto:nashorn-dev@openjdk.java.net>
> <mailto:nashorn-dev@openjdk.java.net<mailto:nashorn-dev@openjdk.java.net
> >>>
> Cc: Elior Apelbaum <elior.apelb...@sapiens.com<mailto:
> elior.apelb...@sapiens.com> <mailto:elior.apelb...@sapiens.com<mailto:
> elior.apelb...@sapiens.com>>>, Moshe Robinov <moshe.robi...@sapiens.com<
> mailto:moshe.robi...@sapiens.com> <mailto:moshe.robi...@sapiens.com
> <mailto:moshe.robi...@sapiens.com>>>, Chen Malka <chen.ma...@sapiens.com<
> mailto:chen.ma...@sapiens.com> <mailto:chen.ma...@sapiens.com<mailto:
> chen.ma...@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.jul...@sapiens.com<mailto:eliezer.jul...@sapiens.com>
> <mailto:eliezer.jul...@sapiens.com<mailto:eliezer.jul...@sapiens.com>>
> Office: +972-3-7902155
> Mobile: +972-50-3697238
> Skype handle: eli_julian
> Visit us at: www.sapiens.com<http://www.sapiens.com> <
> http://www.sapiens.com/>
>
>
