Atanas Roussev – Senior Java Developer, UI Engineer, Web Developer Resume – Vancouver

The purpose of this post is to demonstrate interecepting GWT RPC native calls. This would help GWT developers better understand the low level packet communications, as well as help with debugging and and tampering the requests.

The post is based on the GWT 1.6 StockWatcher example. Tools used are:

• Fiddler (a web debugging proxy)
• HTTP4E (Eclipse HTTP RESTful client)

Assuming you successfully downloaded and installed the Google StockWatcher example and set the project into your Eclipse IDE, run the given StockWatcher.launch task.

And the regular hosted mode shows up.

Clicking SEND makes an AJAX call with a response popup being returned back.

So the question is, what kind of call is that GWT “Remote Procedure Call”? A regular XMLHttpRequest call, JSON, XML, binary? To anylize it, we need to intercept the http packets. So, let’s compile the project using the project ANT build.xml task and a fully compiled web project shows up

/StockWatcher
     /war
          __html's and css's__
          /stockwatcher
                 __compiled JavaScripts's__
          /WEB-INF
                 __servlets, libs, classes, etc..__

Deploy the web project to your favourite WEB container. I am lazy and I simply moved the /StockWatcher/war directory to /tomcat/webapps. Alternatively I could have created a WAR, etc.. That’s not important, the point is you need to have the StockWatcher example running on a web server. To test the app, open a web browser and run the URL http://localhost:8080/<the-name-you-gave-for-this-webapp>/

You should see the page bellow:

So far so good. What we want to accomplish is once again, intercept and tamper that native GWT Remote Procedure Call.

Intercepting GWT RPC call

Open Fiddler and attach it to your browser. Run the application again from your browser and Fiddler should list the GET HTTP calls being transmitted to server:

Click the [Send] button again and observe the HTTP call in Fiddler.

Having the RPC call in Fiddler, we want to dissect it, so let’s switch to HTTP4E, so we can replay it. Copy all the headers from Fiddler to Http4e/Headers Editor. Same for the packet body, copy it to Http4e/Body editor. Hit Run.

And Voila. Running the call from Eclipse HTTP client produced exactly the same response we received while intercepting it with Fiddler.

Few things to notice here:

• The response received is gibberish as it is gzipped.
• There are tons of headers being transmitted, but are they really needed?
• The content-type being send is: Content-Type: text/x-gwt-rpc; charset=utf-8, And this is the most important GWT header. Without it GWT Servlet is not happy and errors out.
• Did you notice the Accept-Encoding: gzip. header? Yes, that’s the one that tells the server we are cool with gzip and GWT server gets back with gzip payload. Removing it stripes out the GWT to a bare regular text

Tampering GWT RPC call

Let’s cut the weed headers and leave just the required content-type. What we are aiming is making a successful tampered GWT RPC call.

Eureka! The call returned 200 Success along with the unzipped RPC content. What’s interesting is that the native RPC response format is actually … drum rolls… JSON !!

There is the //OK or //EX prefix to indicate that response was Success //OK, or Error //EX. Other than that, it’s a well formatted JSON.

What we want to do next is,  tamperig the request and pretend we are a JavaScript native GWT client. The idea is to proove that we can fool the native RPC Servlet. So, modify the RPC argument String “GWT User” to “TAMPERED-REQUEST” and run it again.

RPC responds with 200 //OK !

And that’s all folks. For you, I leave the exercise of:

• exporting the HTTP call to Java (HTTP4E/Export-to-Java)
• make an infinite loop
• and use that expertise when bringing your favourite russian server down with DoS attack

Cheers