当前位置:  开发笔记 > 编程语言 > 正文

GWT RPC - 它是否足以抵御CSRF?

如何解决《GWTRPC-它是否足以抵御CSRF?》经验,为你挑选了1个好方法。

更新: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?有没有办法在纯交叉站点请求伪造方法中设置自定义标头和更改内容类型?



1> rook..:

如果浏览器正在使用此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


XmlHttpRequest,Flash和许多其他技术可以设置自定义浏览器标头 - 但同源策略启动并将阻止其他网站发出请求.除非服务器具有宽松的crossdomain.xml,或者将Access-Control-Allow-Origin返回到任意网站,否则请求如何工作?这只留给我们表格/图片/ iframe等,其中同源政策不适用.但我不知道他们可以设置自定义http标头的方式.那么,它是如何脆弱的?
推荐阅读
跟我搞对象吧
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有