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

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.

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.

XmlHttpRequest, Flash and a host of other technologies can set custom browser headers -- but same-origin-policy kicks in and will prevent another site from making the request. Unless the server has a lenient crossdomain.xml, or is returning Access-Control-Allow-Origin to arbitrary websites, how is the request going to work?That only leaves us with forms / images / iframes and the like, where same-origin-policy doesn't apply. But I don't know of a way in which they can set custom http headers. So, how is it vulnerable?

sri 2010-04-09 18:56:24

.. and yes,I agree token based csrf protection is the best way, but I would like to understand the flaw with their approach.

sri 2010-04-09 18:57:08

@sri Very good question. In order to pull off this exploit you have to take advantage of a little known property of flash. I have posted 2 exploits that do what i am describing, i encourage you to use them. (If you don't have the vulnerable software at the very least you can see that the POST request is being sent to another domain, but the script can't "see" a response due to the S.O.P.)

Rook 2010-04-09 20:24:31

And no i am not relying on a crossdomain.xml file or the "Access-Control-Allow-Origin" header.

Rook 2010-04-09 20:30:52

Thanks for the pointers. I used the code, got stuck, did some research and some tweaking, and finally realized that flash doesn't allow you to set custom http request headers unless the server explicitly allows (see my notes below). But I could set the custom content-type header via flash, and thereby bypass the most-popular version of GWT RPC. So overall, I agree with your answer and recommendation. Thanks!

sri 2010-04-10 20:35:57

@Sri, thanks for the check mark. I am 100% sure you can forge most of the HTTP header and all of the HTTP post using flash and fire off this request to *any http server*. Did you read the article I refereed to in my flash exploit http://www.gnucitizen.org/blog/cross-site-file-upload-attacks/ ?

Rook 2010-04-10 21:52:36

@Sri, here is the official docs for changing the http header:http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/URLRequestHeader.html

Rook 2010-04-10 22:39:32

@The Rook - Yes, I did read the GNU Citizen article. The code listed out there doesn't post non-standard http request headers like X-GWT-Permutation. I had even gone through the API, and as you mention, there is nothing in it that says it can't be done. But when you actually compile and run the example, you get a security error #2046. The only reference I found which says it can't be done waas the 'Flash player 10 security' PDF document.

sri 2010-04-11 04:23:03

@sri, I guess things have changed. Flex 3.2 is dated.

Rook 2010-04-11 04:51:06

@sri, Here are the new rules for setting headers: http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html You can only set them on POST, and the common ones are black listed, according to all of the information you have posted the "X-GWT-Permutation" header element can be controlled for POST requests using the method i used in my cross-site-file upload exploit.

Rook 2010-04-13 16:52:40

Check out this example code that changes the `pragma: no-cache` header element:http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html#URLRequestHeader%28%29If you had trouble compiling my code you should try compiling the example.

Rook 2010-04-13 16:55:22

ansaurus

tags:

views:

answers:

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

related questions