GWT Penetration Testing

Penetration Testing GWT Application:

One of my recent engagements I have got an opportunity to work on Black box application testing which uses Google’s Web Tool Kit. Initially it was difficult to test as the technology was new and all the parameters were obfuscated, but as we went deeper lot of authorization and other security flaws were unfolded.

Google Web Tool Kit:

A) Boot Strap Loading ->cache/no cache Files

GWT requires no plug-in and has less cross browser headaches. Typically when ever application loads every application has a process called as bootstrap process which is kicked off and initiates application initiation process, where process likes browser detection takes place and appropriate compatible java scripts files are created which are supported by the browser., this is done by files called as gwt.js and .nocache.js where deferred binding occurs which acts as boot strap process and loads appropriate configurations , modules and browser specific classes .

{HEX}.cache.html is browser specific files and it consists of application logic which are generated post authentication. They are named according to the MD5 sum of their contents and consist of RPC methods, other restricted methods and sensitive information.

Sample Cache files looks like:
https://www.xyz.com/testapp/9E871855826913D91F95F8F65F4ED9E3.cache.html https://www.xyz.com/testapp/C2C2D9E9AB0BBFD8B66FD43702FAF3B5.cache.html

Security Issue:
HEX}.cache.html are generated post authentication, the file should be restricted and should not be accessible pre-authentication , if accessible this file can disclose sensitive information.

B) Obfuscated Client Side Code :
Google obfuscates code to save space. In GWT all the client side code is downloaded to browser and consists of RPC methods, other restricted methods and sensitive information. These are often obfuscated by GWT and are hidden.

degwt is a utility that de-obfuscates GWT generated java script code and one such example is present at
http://code.google.com/p/degwt/

Sometimes RPC methods can be enumerated and there are enumeration tools which can be used to enumerate these methods Refer the below link, this may or may not be successful all the time

http://blog.gdssecurity.com/labs/2010/7/20/gwtenum-enumerating-gwt-rpc-method-calls.html

Security Issue:

1. If code can be de-obfuscated using tools like degwt can disclose sensitive information to the user.

2. If RPC method enumerated using gwtenum can disclose sensitive RPC information

C) Authorization:

Authorization testing is much easier when all application functionality is available, this is most common flaw in the GWT application, and most of the time authorization controls are not implemented in GWT applications and in the application, most common authorization check are applicable here .

Security Issues:

1. Low level user can perform unauthorized execute by just replaying the request for recorded from the high level user

2. Low level user can read files available to higher level user by just manipulating the parameters.

D) Cross Site Scripting/CSRF:

Most classis script attacks can work here as GWT is not immune to XSS/CSRF, if the JavaScript is not properly coded it’s always vulnerable to XSS/CSRF.

Security Issues:
Perform a through XSS manual and automated testing to identify any XSS Issues.

E) Other Web Vulnerabilities:
Note that GWT RPC services are vulnerable to the same typical vulnerabilities as typical web apps.

Ex. SQL Injection, XFS, Parameter Tampering etc.

References:
http://blog.gdssecurity.com
http://code.google.com/webtoolkit