Question

UPDATE : GWT 2.3 introduces a better mechanism to fight XSRF attacks. See http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.html

---

GWT’s RPC mechanism does the following things on every HTTP Request –

1. Sets two custom request headers – X-GWT-Permutation and X-GWT-Module-Base
2. Sets the content-type as text/x-gwt-rpc; charset=utf-8

The HTTP request is always a POST, and on server side GET methods throw an exception (method not supported).

Also, if these headers are not set or have the wrong value, the server fails processing with an exception “possibly CSRF?” or something to that effect.

Question is : Is this sufficient to prevent CSRF? Is there a way to set custom headers and change content type in a pure cross-site request forgery method?

Answer 1

If this GWT RPC is being used by a browser then it is 100% vulnerable to CSRF. The content-type can be set in the html <form> element. X-GWT-Permutation and X-GWT-Module-Base are not on Flash’s black list of banned headers. Thus it is possible to conduct a CSRF attack using flash. The only header element you can trust for CSRF protection is the “referer”, but this isn’t always the best approach. Use token based CSRF protection whenever possible.

Here are some exploits that i have written which should shed some light on the obscure attack i am describing. A flash exploit for this will look something like this and
here is a js/html exploit that changes the content-type.

My exploit was written for Flex 3.2 and the rules have changed in Flex 4 (Flash 10) Here are the latest rules, most headers can be manipulated for requests POST only.

Flash script that uses navigateTo() for CSRF:
https://github.com/TheRook/CSRF-Request-Builder