We have a huge GWT application, which was never tested for security and now we would like to patch it with some of the "best practices" we have found on the GWT website.

One of those patches is related to the RPC XSRF token, so we applied the code so any call in the application will sue the token, and everything "looks" fine, but now I would like to test it against at least a basic attack, just to be sure that "something is working somehow".

The problem is that the request payload seems to be serialized in some custom way, and there is no evidence of the rpc token.

Is there a simple method for testing this vulnerability? I'm thinking about forging a request with postman, or making a form in another server to make a call, but a basic approach to those solution seems not to work.

I've managed a very dirty way to test the functionality, once the setToken was invoked. I've added a new token string (directly in the code), and the exception is been thrown successfully, so this thing somehow it is working.

Having a way to test it in the wild should be appreciated.

1 Answer 1


I've managed to test it with POSTMAN. the tricky thing to notice is setting all the headers, especially the Content-Type that must be set to: text/x-gwt-rpc; charset=UTF-8. I've taken a payload from a recent request, and then I done the same request with postman, the server answer with a legit peyload. Then, I changed the rpc token in the payload request (I've taken it from the XSRF request during the loading of the app). The served answered with a XSRF Token Error.

So, without a proper Token, no request can be done on the app.

One thing to nice is that the xsrf token is just the md5 of jsessionId, so another way to test it is to change the jsessionID in the chrome console or its md5.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .