Tag Archives: javascript

Java Scripting Vulnerabilites

Recently I had to look into processing user inputted expressions which would enable a user to insert control flow logic into a workflow depending on whatever criteria they wish. We are already using JBoss’s jBPMN which is an implementation of BPMN, a standard workflow schema. It is a stable, trusted and widely used tool in the enterprise community.

jBPMN allows the workflow to have “constraints” where you may inject variables or really whatever you wish and supply either Java code or MVEL expressions to evaluate and ultimately control the flow of the workflow. MVEL is just a subset of Java and provides a nice “scripting” feel while maintaining access to all Java objects and classes without the verbosity of Java. With that said, both Java and MVEL are subject to malicious code should as much as if you were running that code directly not in an interpreter. My first thought was that it was likely that either on the MVEL layer or on the jBPMN layer there are some restrictions added in to safeguard the application and the underlying system. I was wrong. I was able to invoke RunTime.getRuntime().exec("rm -rf /") which will obviously yield some pretty devastating results. I’m assuming that jBPMN was never intended to be written for the purposes of allowing external parties to invoke their own code. However, that is precisely what I needed to accomplish without sacrificing the security of the system.

I looked into using Rhino (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino, https://docs.oracle.com/javase/7/docs/technotes/guides/scripting/programmer_guide/) which is the standard scripting engine available in Java 7. Rhino has now been taken out of the spotlight as Java 8 offers the new and improved Nashorn JavaScript engine. I didn’t evaluate Nashorn regarding security concerns as the project this was related to was limited to using Java 7. I was able to invoke a slightly differently command as I did with Java/MVEL. With Rhino I needed to provide the entire package name, but the outcome was ultimately the same; I was able to invoke the exact same commands as I did earlier.

I looked around and found this blog post (http://maxrohde.com/2015/08/06/sandboxing-javascript-in-java-app-link-collection/) which led me to a simple little library (https://github.com/javadelight/delight-rhino-sandbox). It combines a number of things including the initSafeStandardObjects() method which removes the Java connection entirely. This library also provides some easy ways to still inject desired objects and data.

The result is with a little bit of code I am able to invoke the sandboxed JavaScript within the jBPMN evaluation and having the inputted script written in JavaScript. All I have done is made it that the constraint evaluation will yield a separate evaluation which is then used to return a boolean value indicating whether or not the corresponding step should be invoked or not. In reality this sort of logic would not be limited to JavaScript via Rhino. Once we are separating the execution from reliance on what jBPMN supports there isn’t anything stopping us from supporting any script language that may be invoked in the JVM or on the host machine.

The end goal is we were able to leverage the stability and power of jBPMN without sacrificing our systems security.

Angular 2 – Trial Run

I’m currently still in EST in SF at the Angular U conference. I figured I would give ES6 and Angular2 a try with the official documentation before I hear the keynotes and all.

I started from the “Quick Start Guide” (https://angular.io/docs/js/latest/quickstart.html).┬áSadly right away I found mistakes… The documentation says all that you need to install is the angular2 TypeScript definition. When the compiler runs it turns out you need a number of additional definitions in order to make the code compile:

Maybe the version of the guide hasn’t been updated to reflect changes in Angular.

Well anyways, after this the script did in fact compile and was fairly trivial. Now for my rant. I really love AngularJS. After developing a lot of applications with jQuery and getting fed up with the fact that there was no structure to my applications I set out to look at the various libraries and frameworks that best fit my needs and the demands of most of the projects I work on.

AngularJS was the least “preachy”, most overall functional and forward thinking framework. You didn’t need to embrace any philosophies, file structure, really much of anything. The only mantra that I associated with Angular is no DOM manipulation in anything other than a directive.

After developing with Angular 1.x for a nice chunk of time I have discovered that there is room for improvement and simplification.

Here is my brief list of issues with Angular 1.x. (Some of these are more limitations in its utilization and less issues with the framework directly)

  1. Dynamic modules – Right now officially if you want to use Angular you need to load “all” of your modules at load time in order to use them. For large applications this is not only inefficient, but simply awful. For “websites” this is fine, but full blown web applications may be huge and if they are built to be single page applications you want the entire application to be rendered using one base HTML page. For large applications I use RequireJS to dynamically load needed libraries and scripts as needed. There are 3rd party libraries that dynamically resolve the angular scripts and trigger digests to propagate throughout the application and mix-in the newly loaded modules. This works fine but its a hack at best. Which leads to the next issue.
  2. Config phase restrictions – The config phase of the application is very logical. You have access to the raw modules and are able to modify them as needed prior to initialization. This is reminiscent of Spring Framework for Java that utilizes @Configuration classes to declare the Java Beans. This is performed prior to the dependency injection process which had greatly inspired Angular. Where it lacked was especially with my first qualm. No third party module was able to dynamically load and be able to affect the config phase of the application. For setting up the routing which is one of the core components of a web application, this is a very crucial step.
  3. Directives are overly complex – Everyone says that the two way binding of Angular is what makes it special. They are wrong, directives is where the power of Angular shines. Two way binding is the obvious outcome with a MVC architecture trying to truly separate the application domains. Scope isn’t super complex. I do think some of the restrictions and subtleties of directives make them very awkward and confusing. While I understand the notion that only a single isolated scope can exists on a single element, it can make many directives difficult to work with. The need to manually invoke digests using $scope.$apply because Angular didn’t know otherwise was really messy and almost hackish. I think this was needed because of the lack of support for native Object.observe functionality.
  4. $scope.$watch – If you are dealing with a large application you will want to limit the number of watches you use in your application. I try to avoid them as much as possible. They will consume memory and affect performance. Because the Object.observe function has not been adapted by all browsers Angular needs to perform dirty checking which can be expensive. This results in performance being affected and you are forced to use Angular’s broadcast system.
  5. Broadcast can be improved – Avoiding the scope.$watch when possible forces you to use some sort of event propagation system. Angular has its own $broadcast and $emit calls that send data down and up (respectively through the scope) on the routing key specified. My biggest issue is not as much with the way that the broadcast system works, but rather that it is too limited. I want to see an actual AMQP style event bus that can queue events/messages and use actual routing keys much like you find in RabbitMQ. I have actually developed my own library (https://github.com/CyberPoint/eventBus) that is a JavaScript event bus. It doesn’t deal with Angular scopes at all, but it could. I find being able to use the dot notation hierarchy is just as effective as scope alone.

I hope to post a follow-up entry with how Angular2 addresses these items.