更新：GWT 2.3 引入了更好的机制来对抗 XSRF 攻击。请参阅 http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf。 设置两个自定义请求标头
GWT 的 RPC 机制对每个 HTTP 请求执行以下操作 -
- - X-GWT-Permutation 和 X-GWT-Module-Base
- 将内容类型设置为 text/x-gwt-rpc； charset=utf-8
HTTP 请求始终是 POST，并且在服务器端 GET 方法会引发异常（不支持该方法）。
此外，如果这些标头未设置或具有错误的值，服务器将无法处理并出现异常“可能是 CSRF？”或类似的东西。
问题是：这足以防止 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 -
- Sets two custom request headers - X-GWT-Permutation and X-GWT-Module-Base
- 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?
发布评论
评论（4）
如果浏览器正在使用此 GWT RPC，那么它 100% 容易受到 CSRF 的攻击。内容类型可以在 html
以下是我编写的一些漏洞利用程序，这些漏洞应该可以帮助您了解我所描述的晦涩攻击。 Flash 漏洞利用类似于 this 以及
这里是一个改变内容类型的js/html漏洞。
我的漏洞是为 Flex 3.2 编写的，Flex 4 (Flash 10) 中的规则已更改，以下是 最新规则，大多数标头只能针对请求 POST 进行操作。
使用
navigateTo()进行 CSRF 的 Flash 脚本：https://github.com/TheRook/CSRF-Request-Builder
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-PermutationandX-GWT-Module-Baseare 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 引入了更好的机制来对抗 XSRF 攻击。请参阅 GWT RPC XSRF 保护
GWT 2.3 introduces a better mechanism to fight XSRF attacks. See GWT RPC XSRF protection
我知道我问了这个问题，但经过大约一天的研究（感谢 Rook 的指点！），我想我有了答案。
GWT 提供的开箱即用功能不会保护您免受 CSRF 的侵害。您必须执行 GWT 安全性中记录的步骤应用程序以保持安全。
GWT RPC 将“content-type”标头设置为“text/x-gwt-rpc; charset=utf-8”。虽然我没有找到使用 HTML 表单进行设置的方法，但在 Flash 中这样做很简单。
自定义标头 - X-GWT-Permutation 和 X-GWT-Module-Base 有点棘手。无法使用 HTML 设置它们。此外，除非您的服务器在 crossdomain.xml 中明确允许，否则无法使用 Flash 设置它们。请参阅 Flash Player 10 安全性。
现在 GWT 的 RPC 有两种风格。有旧的自定义序列化格式 RPC 和新的基于 JSON 的 de-RPC。 AFAICT，客户端代码始终设置这些请求标头。旧式 RPC 现在不会在服务器端强制执行这些标头，因此可能会发生 CSRF 攻击。新风格的 de-RPC 强制执行这些标头，因此可能会也可能不会攻击它们。
总的来说，我想说，如果您关心安全性，请确保在请求中发送强 CSRF 令牌，并且不要依赖 GWT 来阻止它。
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.
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.
我不确定是否有一种简单的方法（我也非常想找出答案！），但至少似乎有一些高级方法可以使用任意标头实现任意跨站点请求：http://www.springerlink.com/content/h65wj72526715701/ 我还没买论文，但摘要和介绍听起来确实很有趣。
也许这里有人已经阅读了论文的完整版本，并且可以扩展一点？
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?