由crossdomain.xml安全策略文件引发的一些列安全问题

这是一起由crossdomain.xml安全策略文件引发的思考,不是馒头,也不是血案!!初识是在几年前刚接触Flex的时候,那会懵懵懂懂的解决问题,到如今与其打交道不计其数,这个大问题小问题都能轻松搞定,就是这样惬意的阳光午后,我高高兴兴的写着代码,排着工期,整理文档,计划着今天又可以回家吃饭的时候,收到一封邮件,一封关于部署在都快被忘记的服务器上的flash跨域安全漏洞,要求紧急修复。

擦,what?这不是在搞笑吧,这尼玛是啥?这又什么东东?丈二和尚摸不着头脑,安全漏洞?于是果断的查找服务器策略文件,果不其然,没部署,是的没有部署安全策略文件,哎哟我去啊,这不是我干的,我来的时候就有它了,吧啦吧啦的……说别的没用啊,现在得解决问题啊,那就搞一个crossdomain.xml文件放到服务器下面呗,可不,啪啪啪,几下键盘,2分钟搞定,如此简单的小问题,呵呵呵哈哈哈哈...就在哥以为可以回邮件的时候,看到乌云跨域漏洞字样,打开瞅瞅是啥玩意,这一看不要紧,可吓死我了,根本看不懂啊,忒多,各种乱七八糟的代码段,解释,最主要也是心急,知道这下完了,下午的时间估计要花费在这个该死的漏洞上了。。


=======================正式开始=======================


1、这是个什么漏洞?

通过对CVE-2011-2461原理分析及案例的认真研读和学习,我们很容易知道,这个漏洞能够让黑客们很容易很轻松的加载我们服务器上的SWF文件,伪装成我们安全域下的沙箱文件,窃取用户的隐私信息。(虽然并没有什么东西能够窃取到,窃取直播的视频流?好吧,即使没什么怕偷走的,还是修复的好!)

2、这是什么引起的?

原因文章中也详细分析了,是由于安全域授权时采用“导入式加载”的方式造成,我们在Adobe官方提供的API文档中(详见导入加载LoaderContext.securityDomain)也可以发现其具体介绍。


3、真的有这样的漏洞么?

是的,在SDK4.6版本中确实存在,乌云平台也不能瞎说呀。博主根据文章中介绍的顺序仔细认真的分析过swf流程加载的顺序,核对过每个提到的代码段,加载原理,最终在ModuleManager.as类中L463行找到如下代码段。


就是文中最后提到的内容。

4、如何修复这个漏洞?

这个也不用咱们操心,文章中都有讲,而且这漏洞还是历史漏洞,文章中给出了四种解决办法,如下:

对于这个漏洞,修复与防御措施可能有如下几点:

  • 更新开发工具

  • 对于采用老版本SDK编译产生的swf文件,可以使用新版本的开发工具重新编译一下,或者采用修复工具对swf进行补丁(https://helpx.adobe.com/flash-builder/kb/flex-security-issue-apsb11-25.html)。当然,如果文件已经很古老,直接暴力的删掉就好了。

  • 将swf等存在安全风险的静态资源文件放置到独立的域名下,可最大程度避免此类问题。

  • 开发者在编写相关代码时,应该尽量避免使用“导入式加载”;在使用Loader类时,应该对加载的URL进行合法性判断。

我们重点关注一下,提到的工具,其实是Adobe对这个漏洞的讲解和修复手段。

5、Flex Security Issue APSB11-25一文中,提到了两种解决办法,一种临时应急的解决方案,一种一劳永逸永久性的解决方案,当然大家都知道肯定是第二种靠谱。

官方漏洞地址工具地址,需要电脑安装air环境

应急方案:是下载官方提供的修复工具,对存在漏洞的swf文件,修复,操作简单快速,可行。

永久方案:更新开发者使用的SDK版本,按照文中介绍4.6以上的SDK已经修复了这个问题,可是博主用的也是4.6的SDK,但真真的有这个问题,想到还有4.13的SDK存在,于是果断替换SDK,重新编译,发布,用漏洞工具检测,结果显示不存在漏洞,查看ModuleManager.as类发现代码段有变化,如下:


我们还可以根据提到的命令行解析成文本的方式进行验证,命令行切换到FB的安装路径,然后进入sdks/bin,执行swfdump -abc -路径/xxx.swf > 路径.txt,这样就把swf二进制搞成了txt文本格式,对修复前和修复后的两个swf文件执行上面命令,然后使用文件对比软件Beyond compare(博主电脑很早之前安装,很有用的软件,其他对比软件亦可)结果如下:


这个对比结果只有两处不同,第一个是文件名,博主自己命名的,无关紧要,第二处就是上面的图中,也就是说前后的对比能够发现确确实实是通过修改的ModuleManager.as中那段代码能够解决问题,乌云平台和官网给的都是可行方案。

6、博主要说的?

博主一直很啰嗦,异想天开的我以为自己更改4.6SDK中的ModuleManager.as可行,那可不可以呢,答案是不可以的,虽然我手动把代码修改成功,但完全是欺骗自己啊,就自己知道更改过,FB编译器不知道,因为没编译没运行,系统SDK需要打包重新ant才可。

7、更改后有什么影响?

选择工具修复,除非以后不维护代码,这种不安全的修正措施,万一后期那个倒霉的程序员忘记工具修复就等着挨批吧。那是不是说换高版本的SDK就可取呢,高版本的SDK需要高版本的flash player插件支持,可能会影响用户体验,需要更新自身插件才能用,不过说回来,大多数用户电脑上的FP都是新版的,目前来说是17beta版本,而SDK4.13只要求fp14.0以上就可。那为什么不适用SDK4.7呢或者SDK4.6A啊,博主认为那些SDK也存在漏洞,不想每天都为了修复漏洞浪费时间啊。


博文中应该再加几张图的,可是下班后还没吃饭。。想想就算了吧,真正想看的关心的没几个,而且提到的两篇文章都比较详细,我这里也只不过是做了介绍而已。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章