GWT RPC - 它是否足以抵御CSRF？ [英] GWT RPC - Does it do enough to protect against CSRF?

问题描述

更新：GWT 2.3引入了更好的机制来应对XSRF攻击。请参阅 http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf .html

---

GWT的RPC机制在每个HTTP请求上执行以下操作 -

1. 设置两个自定义请求标头 - X-GWT-Permutation和X-GWT-Module-Base


2. 设置内容-type as text / x-gwt-rpc; charset = utf-8

HTTP请求总是一个POST，在服务器端GET方法抛出一个异常（方法不支持） 。

另外，如果这些头文件没有设置或者有错误的值，那么服务器将无法处理，但可能会出现可能的CSRF？异常。或者这样的事情。

问题是：这足以防止CSRF吗？有没有一种方法可以在纯粹的跨站点请求伪造方法中设置自定义标题和更改内容类型？

如果这个GWT RPC正在被浏览器使用，因此它对CSRF 100％易受攻击。内容类型可以在html < form> 元素中设置。 X-GWT-Permutation 和 X-GWT-Module-Base 不在Flash的黑名单中禁止标题。因此可以使用闪存进行CSRF攻击。您可以信任CSRF保护的唯一标头元素是引荐者，但这并不总是最好的方法。尽可能使用基于令牌的CSRF保护。

以下是我写的一些漏洞，应该对我所描述的晦涩攻击有所了解。对此的Flash利用将看起来像这和
这里是一个改变内容类型的js / html漏洞利用。

我的漏洞是为Flex 3.2编写的，并且规则在Flex 4（Flash 10）中发生了变化。这里是 latest rules ，大部分头文件只能被POST操作。

对于CSRF使用 navigateTo（）的Flash脚本：
https://github.com/TheRook/CSRF-Request-Builder

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?

解决方案

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 RPC - 它是否足以抵御CSRF？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！