GWT RPC - Does it do enough to protect against CSRF?

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 开发者_StackOverflow中文版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?

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

GWT 2.3 introduces a better mechanism to fight XSRF attacks. See GWT RPC XSRF protection

I know I asked this question, but after about a days research (thanks to pointers from Rook!), I think I have the answer.

What GWT provides out-of-the-box will not protect you from CSRF. You have to take steps documented in Security for GWT Applications to stay secured.

GWT RPC sets "content-type" header to "text/x-gwt-rpc; charset=utf-8". While I didn't find a way to set this using HTML forms, it is trivial to do so in flash.

The custom headers - X-GWT-Permutation and X-GWT-Module-Base, are a bit more tricky. They cannot be set using HTML. Also, they cannot be set using Flash unless your server specifically allows it in crossdomain.xml. See Flash Player 10 Security.

In addition, when a SWF file wishes to send custom HTTP headers anywhere other than its own host of origin, there must be a policy file on the HTTP server to which the request is being sent. This policy file must enumerate the SWF file's host of origin (or a larger set of hosts) as being allowed to send custom request headers to that host.

Now GWT's RPC comes in two flavours. There is the old, custom-serialization format RPC, and the new, JSON based de-RPC. AFAICT, client code always sets these request headers. The old style RPC doesn't now enforce these headers on server side, and thus a CSRF attack is possible. The new style de-RPC enforces these headers, and thus it may or may not be possible to attack them.

Overall, I'd say if you care about security, make sure you send strong CSRF tokens in your request, and don't rely on GWT to prevent it for you.

I'm not sure, if there's an easy way (I'd be extremely interested in finding that out, too!), but at least there seem to be some advanced ways to achieve arbitrary cross site requests with arbitrary headers: http://www.springerlink.com/content/h65wj72526715701/ I haven't bought the paper, but the abstract and introduction do sound very interesting.

Maybe somebody here already read the full version of the paper, and can expand a little bit?