Flash应用安全规范

Author: jianxin [80sec]
EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2009-07-25
From: http://www.80sec.com/release/flash-security.txt

[ 目录 ]

0×00 前言
0×01 安全的服务端flash安全策略
0×02 安全的客户端flash安全规范
0×03 flash安全的checklist

0×00 前言

flash作为一款浏览器的第三方插件，是对浏览器功能的延伸，已经是web必不可少的元素。但是这种延伸必然带来不安全的因素，相比于安全性已经得到磨练的浏览器来说，flash绝对是客户端安全的一个软肋（包括在比较神秘的漏洞挖掘领域，也是这个观点），同样flash在页面展示时所含有的丰富功能，在某些情况下你甚至可以认为它等同于javascript，甚至更为危险。浏览器所贯彻的域安全策略被flash所打破，客户端所做的种种过滤也同样被 flash所打破（只要你还使用flash）。但是flash也已经感觉到了这个问题，并且时时在改进，在设计上也引入了一些比较好的安全机制，恰当的使用这些安全机制可以避免你的应用程序遭到攻击。80sec将从实际的一些经验总结出一些供参考的flash使用规范，规范将从服务端应用程序的安全设计和客户端的flash安全使用两个角度来说明这个问题。

0×01 安全的服务端flash安全策略

应用程序安全设计的时候应该秉承最小化原则，在flash的大部分应用中，由于功能需求就经常需要跨域获取数据。域安全是浏览器安全的基本策略，flash作为浏览器的扩展允许跨域获取数据就从根本上打破了浏览器的安全性。flash以flash文件存储域名作为它的当前域，如果需要获取其他服务器上的数据就会发生跨域行为，而且该跨域行为会继承用户浏览器里的认证信息，限制不严格时将导致安全漏洞，打破我们的整个客户端安全模型。flash 在跨域时唯一的限制策略就是crossdomain.xml文件，该文件限制了flash是否可以跨域获取数据以及允许从什么地方跨域获取数据。通过严格控制该策略文件我们就可以为应用程序安全和功能上寻找到一个平衡点。

典型的crossdomain.xml文件策略
<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*.80sec.com" /> </cross-domain-policy>
其中最主要的策略是allow-access-from表示允许来自哪些域的跨域请求，早期的flash允许从其他位置载入自定义的策略文件，目前最新版的flash在接受自定义的策略文件之前会去检查主目录的crossdomain.xml来判断是否接受自定义策略文件。该选项由
<site-control permitted-cross-domain-policies="by-content-type"/>
节点控制，不加该选项时，默认情况下flash不加载除主策略文件之外的其他策略文件，即只接受根目录里的/crossdomain.xml。这对于防止利用上传文件来定义自己策略文件的攻击非常有效。为了在某些条件下需要启用其他策略文件，我们需要设置permitted-cross-domain- policies，设置为by-content-type时将会只允许http头为text/x-cross-domain-policy的策略文件，当为all时则允许所有的text/xml等格式的策略文件。

应用程序在设计的时候按照最小化原则

1 将文件上传和应用的域名分开，防止通过上传flash文件直接获得域操作的权限。
2 对于不需要使用flash的应用严禁在域名目录下部署flash策略文件。
3 对于有功能需求的应用遵循最小化原则将域名限制到最小的范围，有安全需求的应用应该明确允许跨域请求的域，禁止直接使用*通配符，这将导致跨域访问权限的扩散。

譬如http://sns.80sec.com/crossdomain.xml
<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*.80sec.com" /> </cross-domain-policy>
就对权限设置过泛，可能导致其他安全策略的绕过（如绕过csrf等等）

4 对于有高安全需求的应用，在限制域名的前提下，将需要被flash访问的应用限制到指定目录，并且在flash内指定策略文件到该目录以将所有访问权限限制到单一目录。

如果login.80sec.com中的某个功能如login需要对所有域名开放，如果配置根目录crossdomain.xml
<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
不是一个好的策略因为他不只会开放login同时会开放如chgpassword等其他的服务给用户，我们需要配置主策略文件
<?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="all"/> </cross-domain-policy>
然后自定义策略文件到一个目录如/flash/crossdomain.xml
<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
并且将login应用部署到/flash/目录，用户的访问将被限制到/flash/下面，无法对其他功能进行操作。

0×02 安全的客户端flash安全规范

控制好flash安全策略并不是安全的全部，这样只能保证服务端的安全。由于一些功能上的原因，譬如为了追求良好的用户体验，为了让无聊的用户可以在页面共享各种flash，为了把页面做得华丽丽的，我们往往需要在页面内容里嵌入flash，这个时候安全性就会被抛到一边（我们还是建议如果不需要的话还是少用这种动态的东西）。我们在一个页面引入一个flash时，一般的做法是下面这种形式：
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" name="Main" width="1000" height="600" align="middle" id="Main"> <embed flashvars="site=&sitename=" src='Loading.swf?user=453156346&key=df57546b-c68c-4fd7-9f9c-2d105905f132&v=10950&rand=633927610302991250' width="1000" height="600" align="middle" quality="high" name="Main" allowscriptaccess="sameDomain" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" /> </object>

由于flash的强大，并且在页面元素里基本等同于script这种危险的标签，对于这点，flash已经有所考虑，在引入flash的时候flash提供了控制属性，其中与安全最为关键的是AllowScriptAccess属性和allowNetworking属性。其中 AllowScriptAccess控制flash与html页面的通讯，可选的值有：
always //对与html的通讯也就是执行javascript不做任何限制 sameDomain //只允许来自于本域的flash与html通讯，这是默认值 never //绝对禁止flash与页面的通讯
默认情况下的选项是sameDomain，这个时候某些场景下看起来也是足够安全了，但是我们还是能看到经常有程序允许将这个选项设置为always，而即使是sameDomain也不是在所有场景下都安全的，考虑如论坛这样的程序，上传和展现都是在同一个域的情况下，就不存在任何安全性可言了，我们强烈建议该选项为never，如果你选择sameDomain或者always我也希望你清楚自己在做什么。

allowNetworking控制flash与外部的网络通讯，可选的值包括：
all //允许使用所有的网络通讯，也是默认值 internal //flash不能与浏览器通讯如navigateToURL，但是可以调用其他的API none //禁止任何的网络通讯
但是最近更新的flash客户端貌似是只要AllowScriptAccess被设置那么包括navigateToURL都不能使用，在官方文档上也只看到简简单单的一句道歉，但是这样的确从某些程度上提高了嵌入flash的安全性。但是即使不跳转，我们还是能做很多事情，当我们将flash直接嵌入到页面又没有设置allowNetworking时，我们就可以做csrf之类猥琐的事情，更要命的是这种形式的csrf支持POST请求，referer来源为swf文件所在地址或者为空，同时发送所有cookie而不像图片那些只能发送session cookie，而且基本没有任何的痕迹，基本秒杀那些没有做token保护的csrf防范了，之前的开心网犯的就是这个错误，我们强烈建议该选项为 none，如果你不选择这个建议你也要清楚自己在做什么。

0×03 flash安全的checklist

1 检查自己的网站的根目录的crossdomain.xml

好孩子：
http://mail.google.com/crossdomain.xml http://youa.baidu.com/crossdomain.xml http://www.adobe.com/crossdomain.xml
坏孩子：
http://www.youku.com/crossdomain.xml http://www.renren.com/crossdomain.xml http://www.taobao.com/crossdomain.xml
我承认所有的利用都离不开场景，有的时候如果实在没有办法修改这个crossdomain.xml（这个情况的确存在，譬如某些变态功能的需要），那么就可以考虑在应用程序获取数据时对提交的数据做校验，譬如当请求的头里包括x-flash-version时，就可以判定来源是flash而不予响应，但这的确不是一种优美的解决办法。

2 检查自己网站引入flash的代码

有AllowScriptAccess和allowNetworking么？如果没有，那是不是我这个应用设计已经很安全足够抵御各种攻击了?

如果想针对安全问题做测试，fly_flash是方便的攻击客户端的好伙伴（参见开心网蠕虫），如果想针对第一种错误的策略文件突破csrf等做测试就还得自己写源码了。另外，良好的设计的最大敌人就是坏的实现，原因也是各个程序之间天然的心之壁垒，猜猜
<embed allowscriptaccess="always" allowscriptaccess="never" height=384 width=454 src=http://www.80sec.com/fly_flash.swf?sec80=http://www.80sec.com/fly_flash.txt&x.swf wmode="transparent" loop="false" autostart="false">
这段代码的结果是什么?