更新：GWT 2.3引入了更好的机制来对抗XSRF攻击。见http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.html
GWT的RPC机制在每个HTTP请求上执行以下操作 -
HTTP请求始终是POST，在服务器端GET方法抛出异常（不支持方法）。
此外，如果未设置这些标头或具有错误的值，则服务器会因“可能是CSRF？”而异常处理。或类似的东西。
问题是：这是否足以阻止CSRF？有没有办法在纯交叉站点请求伪造方法中设置自定义标头和更改内容类型？
答案 0 :(得分：6)
如果浏览器正在使用此GWT RPC，则它100％容易受到CSRF的攻击。可以在html <form>元素中设置content-type。 X-GWT-Permutation和X-GWT-Module-Base不在banned headers的Flash黑名单中。因此，可以使用闪存进行CSRF攻击。您可以信任的唯一标题元素是CSRF保护是“referer”，但这并不总是最好的方法。尽可能使用基于令牌的CSRF保护。
以下是我写过的一些漏洞，它们应该对我所描述的模糊攻击有所了解。对此的Flash漏洞利用看起来像this和。{ here是一个改变内容类型的js / html漏洞。
我的漏洞是为Flex 3.2编写的，并且Flex 4中的规则已经更改（Flash 10）以下是latest rules，只有POST请求才能操作大多数标头。
对CSRF使用navigateTo()的Flash脚本：
https://github.com/TheRook/CSRF-Request-Builder
答案 1 :(得分：4)
GWT 2.3引入了更好的机制来对抗XSRF攻击。见GWT RPC XSRF protection
答案 2 :(得分：3)
我知道我问了这个问题，但经过大约一天的研究（感谢Rook的指点！），我想我有答案。
GWT提供的开箱即用功能不会保护您免受CSRF的侵害。您必须采取Security for GWT Applications中记录的步骤才能保持安全。
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 Security。
此外，当SWF文件希望时 随地发送自定义HTTP标头 除了它自己的原产地， 必须有一个政策文件 请求所在的HTTP服务器 被送了。此策略文件必须 枚举SWF文件的主机 原点（或更大的主机集）为 被允许发送自定义请求 该主机的标头。
现在GWT的RPC有两种版本。有旧的自定义序列化格式RPC和新的基于JSON的de-RPC。 AFAICT，客户端代码始终设置这些请求标头。旧样式RPC现在不在服务器端强制执行这些标头，因此可以进行CSRF攻击。新样式de-RPC强制执行这些标头，因此可能会或可能不会攻击它们。
总的来说，我会说如果您关心安全性，请确保在您的请求中发送强大的CSRF令牌，并且不依赖GWT来阻止它。
答案 3 :(得分：0)
我不确定，如果有一个简单的方法（我也非常有兴趣找到它！），但至少似乎有一些先进的方法来实现任意标题的任意跨站点请求： http://www.springerlink.com/content/h65wj72526715701/我没有买过论文，但摘要和介绍听起来很有趣。
也许有人在这里已经阅读了论文的完整版本，并且可以扩展一点点？