lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: 3 Jan 2007 14:10:28 -0000
Subject: Hacking AJAX DWR Applications

By Guy Karlebach & Amichai Shulman


The introduction of AJAX into a web application improves the user experience significantly.  However, the complexity of some AJAX frameworks and the limited field experience with them requires a careful examination of potential vulnerabilities.
DWR is a Java open source library, which has already been incorporated into several web sites.  It is composed of two main parts:
•	A Java servlet that runs on the server.  This servlet processes requests that arrive from clients and sends back responses.  
•	Javascript code that is executed on the browser, and sends requests to the servlet.
The Javascript code for method invocation is generated by the DWR framework.  The web application designer only needs to embed the returned values in his web pages.
At the time this document is written the DWR stable release is 1.1.3.  Version 2.0 is under development.  The two versions differ by several features, though both share the vulnerability that we discuss in the next section. 

Forceful Method Invocation Attacks

DWR 1.1.3 provides a configuration option that forbids the invocation of class methods.  This exclusion can be applied to some or all of a class’s methods, and it is configured in the dwr.xml file.  DWR 2.0 adds an additional configuration option that includes JAVA code annotations.  However, both methods enforce their restrictions only on the client side. Therefore, by manipulating HTTP requests through a proxy, excluded methods can be invoked. This also applies to public methods that are inherited from super classes.
As a consequence of the above vulnerability restricted operations may be unintentionally exposed to web users.
2.1	Example:  The TestClass class methods
The following test was repeated in DWR releases 1.1.3 and 2.0, and with all of the possible method exclusion mechanisms for each release.
We created a class named TestClass with two methods:  forbiddenTestMethod and allowedTestMethod.  Both methods were defined as public (private and protected methods are not vulnerable to invocation by the client).  forbiddenTestMethod was excluded using the exclusion mechanism.  The result of this exclusion was that DWR did not provide the browser with Javascript code that generates requests for forbiddenTestMethod.  At this point, we used the browser to generate the following legitimate request (this example is taken from the 2.0 release test):


We then changed the parameter methodName to forbiddenTestMethod, and sent the request to the server.  We received a HTTP 200 OK response with the output of forbiddenTestMethod.

Denial of Service Attacks

There are several ways to send very costly requests to a web application that uses DWR.  We present here several ways by which a malicious user can manipulate DWR requests and create denial of service attack vectors. 

Example:  The Date class
The Java clone method is implemented as a public method by several native library classes, for example java.lang.Date.  If a class that implements clone is available for client side calls, a batch call that executes clone calls can be sent to the server.  This will have a steep performance cost, due to the memory space that the cloned objects occupy.  We tested the following attack vector (Embedded in a HTTP request body) on the DWR stable release running on JBoss, and witnessed a sharp rise in CPU usage:


Furthermore, in the DWR stable release, the following short attack vector causes the servlet to throw an OutOfMemoryError exception:


In the latter case, only one Date object is created, but the server attempts 1000000 clone calls, which exhaust the VM’s memory resources.  Limiting the number of calls in a batch is therefore essential for preventing denial of service attacks of this sort.


We suggest several options for mitigation, all of which require writing Java code:
•	Don’t expose classes that have methods which should not be invoked by the client.  This approach should be applied during the application’s development.
•	Instead of exposing class A and all of its methods, create and expose a class ProxyA.
•	ProxyA relates to A in a has-a relationship.  That is, one of the private class fields of ProxyA is an A object.
•	The methods of ProxyA can be used for calling only those methods of A that may be invoked by the client.  This approach can be applied to an application without changing the code of existing classes.
•	Add stubs to override inherited methods which should not be exposed.  For example, create a toString method that returns an empty string.

Powered by blists - more mailing lists