更新:GWT 2.3引入了更好的机制来对抗XSRF攻击.请参阅http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.html
GWT的RPC机制在每个HTTP请求上执行以下操作 -
设置两个自定义请求标头 - X-GWT-Permutation和X-GWT-Module-Base
将content-type设置为text/x-gwt-rpc; 字符集= utf-8的
HTTP请求始终是POST,在服务器端GET方法抛出异常(不支持方法).
此外,如果未设置这些标头或具有错误的值,则服务器会因"可能是CSRF?"而异常处理.或者那种效果.
问题是:这是否足以阻止CSRF?有没有办法在纯交叉站点请求伪造方法中设置自定义标头和更改内容类型?
如果浏览器正在使用此GWT RPC,则它100%容易受到CSRF的攻击.content-type可以在html 元素中设置.
X-GWT-Permutation
并且X-GWT-Module-Base
不在Flash的禁止标题黑名单上.因此,可以使用闪存进行CSRF攻击.您可以信任的唯一标题元素是CSRF保护是"referer",但这并不总是最好的方法.尽可能使用基于令牌的CSRF保护.
以下是我写过的一些漏洞,它们应该对我所描述的模糊攻击有所了解.对此的flash漏洞看起来像这样, 这是一个改变内容类型的js/html漏洞.
我的漏洞是为Flex 3.2编写的,Flex 4中的规则已经改变(Flash 10)这是最新规则,大多数头文件只能用于POST请求.
navigateTo()
用于CSRF的Flash脚本:https:
//github.com/TheRook/CSRF-Request-Builder