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

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?

Frederic

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

Systematism

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? – Frederic

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

@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.) – Systematism

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

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! – Frederic

@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 gnucitizen.org/blog/cross-site-file-upload-attacks ? – Systematism

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

@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. – Frederic

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

@Systematism : Please update your links. So if I understand, it’s possible to send post requests with credential without being able to get the response ? – Isadora

@Systematism : -1. The answer is irrelevant without the explanation on how to send a cross origin post that ignore crossdomain.xml in flash. – Isadora

@Isadora crossdomain.xml does not mitigate navigateTo() based CSRF - github.com/TheRook/CSRF-Request-Builder This probably did work when this post was made - but flash has changed a lot since 2010. – Systematism

@Systematism : and does an old flash file for older flash player version would work ? Or does flash functions are relevant of the installed plugin instead of the swf executable ? You should put the answer in that answer. – Isadora

Answer 2

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

Cantlon

did any independent party verify that the current (GWT 2.8.1) XsrfTokenServlet implementation provides a safe way to protect against XSRF? – Scribe

Answer 3

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.

Frederic

@sri, Here are the new rules for setting headers: 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. – Systematism

Check out this example code that changes the pragma: no-cache header element: eonflex.com/flex/4.1/langref/flash/net/… If you had trouble compiling my code you should try compiling the example. – Systematism

Your answer was exactly what I was looking for, but it dates back from 2010. I'm trying to write a PoC CSRF attack against the old-style RPC, using a modern version of flash. Do you know if this is still possible? As the target doesn't have a crossdomain,xml. It looks like my Flash client is sending a request for crossdomain,xml to the server, realises there is no such file, and then doesn't proceed to issue my CSRF payload. Have new versions of Flash essentially prevented this kind of attack, even on the old-style RPC? – Petaloid

Answer 4

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?

Siddur

I posed to flash source code that i wrote which modifies http headers and post to exploit a csrf vulnerability. – Systematism

@Systematism : but please re‑post it. – Isadora