Policing user input
Bringing the security protection of the application into the JVM also means that user input can be tracked throughout program execution. This feature, called "variable taint tracking," can prevent the use of untrusted user input for data access (such as SQL queries) or sensitive operations (reflection) without proper validation. Taint tracking prevents code injection attacks (like SQL injection) by stopping malicious or malformed user input from being passed from an untrusted source to a trusted resource (as from an HTTP query string to a SQL database).
By blocking the execution of malicious code regardless of where it originates -- in the application code, imported third-party libraries, or the network -- a RASP-enabled JVM can defeat zero-day exploits. Furthermore, security administrators can add new rules to a running app without restarting or interrupting application service, allowing them to thwart a new exploit as soon as it is understood and without waiting for vendor-supplied patches.
Waratek Application Security for Java also provides application protection for legacy Java security issues -- namely, vulnerabilities in older and unsupported versions of Java. Because Waratek creates a virtual execution environment (or "wrapper") for the application as well as for the JRE (Java Runtime Environment) that the app uses, legacy apps with a legacy version of Java (such as Java SE 5) can run on top of a Java SE 7 version of the Waratek JVM. Without any modifications to the app, Waratek will protect against all of the old -- and new -- exploits that would otherwise succeed.
The Waratek JVM can also pass data to a centralized security event system for correlation with other suspicious activity, or to developers for use in the coding or testing stage.
RASP in action
Two examples of the protection provided by Waratek Application Security for Java include SQL injection attack mitigation using "variable taint tracking," and mitigation of the Apache Struts 2 vulnerability.
As mentioned, SQL injection attacks are a high-priority security risk. Waratek counters this risk by adding metadata to untrusted user input as it enters the JVM. It then tracks what happens to that data as it is used to construct a complete SQL statement to query a database. It can then tell with certainty and act appropriately if the resulting query contains code that will change the meaning of the request, since that means that an attack is being attempted.
Waratek can detect SQL injection attacks with certainty because it is able to examine each and every SQL statement with complete contextual awareness, rather than try to guess based on partial statements, as Web firewalls must do. Again, this mitigation does not require any changes to the application code.
Apache Struts 2 is an open source Web application framework for developing Java Web applications. In the last several years, we've learned of many critical vulnerabilities in the Struts framework that would allow an attacker to execute remote exploits on a vulnerable server.
To remediate these vulnerabilities, users had to wait for an official patch (in some cases for weeks or months), test the patch, then deploy it. Alternatively, they could rewrite their code, again retesting and redeploying the application.
With Waratek, however, applying a single security rule, at runtime and without restarting or interrupting the application, blocks the execution of the compromised function and prevents exploitation.
False positives are always a concern with any security solution, especially for mission critical applications. RASP generally -- and Waratek Application Security for Java specifically -- reduces this risk to an absolute minimum because it is able to monitor the application's behavior and context at a very granular level by watching execution within the runtime environment. This approach is much finer-grained than detection at the network level; therefore, modeling the app behavior for pre-deployment tuning is relatively straightforward.
Finally, while no security process is completely free of processing overhead, placing the security operations inside the JVM where they can be optimized by the JIT (Just-In-Time) compiler ensures that the performance impact is as small as it can be. The performance benefit of native "in-JVM" security is especially pronounced when compared to other application security approaches that use remote procedure calls (like REST API calls) to services outside of the application or "instrumentation agents" to insert debugging-like hooks into application code.
Clearly, an inside-out approach to securing Java applications offers many advantages. By bringing security into the JVM, we can secure an enterprise's most critical code in a way that is always available, does not impact performance in any discernible way, can protect multiple apps, does not require software changes, and is faster and more flexible than patching. Going forward, the same concept can be extended to any application platform with a runtime execution environment, such as client-side Java.
John Matthew Holt is the founder and chief technology officer of Waratek.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.
This article, "How to solve Java's security problem," was originally published at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.