【翻译】Flash播放器9的安全设置变动（第一部分）

Flash播放器9的安全设置变动（第一部分）
2003年flash播放器7引入了一种新的客户端服务端的通信机制，这对于当时的Web界来说还是新的，直接跨域的数据装载，通过政策文件完成认证。在政策文件之前Web内容的装载只能通过在同一个服务器上通过双方的通信完成。诸如：运行时配置和处理而不需要重新装载页面。政策文件允许服务器选择性的向客户端开放来自其他域的内容，或者更通俗一点说来自任何地方的内容。自从策略文件被引入后，域边界对丰富体验的因特网引用的束缚被大大的消减了。
和大多数的新技术一样，策略文件在刚开始被引入的时候不是完美的，四年后因特网安全社区发现了两种不应该出现的情况（在后面会谈到）从策略文件的产生中出现了，前提是只要策略文件是正确的，而且flash开发人员继续依赖flash6以来出现的策略文件。为了阐述这些问题，Adobe尝试着为策略文件的使用制定更严格的机制。在这篇文章里面我们将尽可能简单明了，清楚的阐述我们为什么要做出这样的改动。
本文假定读者对策略文件有一定的了解，至于策略文件的详细介绍，读者可以参阅adobe的在线文档的跨域策略篇章
为了遵循更严格的规则，站点的策略文件需要做一些微小的变动，这些变动是为了保护站点自身的利益，特别是为了遵循新的策略文件的更严格的规范。
对于大多数的站点，我们认为这种变动是很简单的，但是由于涉及到的站点数目巨大，Adobe将分两步完成策略文件的改进。第一阶段从flash播放器9,0,115,0,，一些小部分严格的规则将被立即强制执行，任何对这些规则的违反都会导致falsh播放器debug版本里可视的警告框。在第二阶段，这一阶段将在flash播放器的下一个版本里开始，第一阶段中出现的那些警告将变为错误，这样过度到更加严格的策略文件的步骤就完成了
1.直接：直接阅读策略严格性的部分，这一步只对那些服务端兼容swf内容网站有效
2.时间空余：如果时间允许那么阅读源策略，然后按照流程选择并配置一个元策略，这些步骤主要对那些已经提供策略文件，但同时也能提供可用的防御测试来应对那些没有策略文件的swf文件
3.时间裕度：如果时间允许，那么阅读socket策略文件，然后按照流程配置socket策略。这一步主要对那些已经提供socket策略文件，但是同时也能提供可用的防御措施来应对那些没有策略文件和swf内容
需要阐述的内容

策略文件控制：
有这样的可能性，即服务器上的某个文件看起来不是策略文件但是却可以被用作策略文件。例如如果网站支持文件上传，但是并不支持跨域的数据传输，这个时候用户就可以创建一个策略文件上传到站点并将其伪装为策略文件，例如通常的text文件，xml文件，或者是html文件甚至是二进制文件例如png或者是jpeg图像文件。成功创建了这样的伪装策略文件的时候，用户就可以构建一个flash的应用向网站发出跨域传输数据的请求。类似的受限制的网站用户也可以创建这样的一个伪装文件来破坏网站管理员的愿望，甚至是偶然的创建一个他们并不愿意的策略文件。这个问题本质上是什么样的策略文件才能被允许放在站点上，服务器的管理员应该能够来制定这样的一个策略即既能够设置服务端的策略文件放置策略（我们称为元策略），也能够容易的搜索到服务器上所有的策略文件。而允许所有的跨域传输安全的在服务器上进行。更严格的策略文件规则允许网站管理员来申明这样的元策略，并进行完整性检查以保证所有的策略文件都是合法的形成的。
（更多内容尽在http://blog.csdn.net/zinking3 大家一起来关注RIA )
DNS加强：一种称为dns重定向的攻击能够正对flash播放器以及浏览器，虚拟机，以及其他的用户中介程序。这种攻击利用了用户中介的同源策略，即来自一个特定域的内容可以在不显式申明的情况下同这个域的其他内容进行通信。一个攻击者如果控制着自己的域并且有自己的dns服务器，那么他们就可以动态的配置dns以使得用户中介程序将特定的域名解析为攻击者想要的IP地址（此站点可能包含着恶意的内容）然后将地址解析为一个不同的攻击者并不控制的IP地址，如果用户中介程序没有发现服务端的Ip地址变动，它的同源策略将允许攻击者的内容来访问第二个IP地址而不需要认证。flash播放器以来浏览器来实现HTTP网络协议，所以任何关系到浏览器脆弱性的问题必须在浏览器层面得到解决，flash播放器也通过as socket 以及xmlsocket提供socket通信，Flash Player 9,0,115,0更严格的策略文规则将减轻这种dns重定向攻击的脆弱性，这种更严格的规则需要socket策略文件允许创建一个socket链接，即使目标的服务器是同源的情况下，另外从此版本开始flash播放器将socket连接和ip地址绑定，而不是仅仅和域名绑定

其他改进：
在陈述上面的问题的时候我们也为策略文件添加了一些新的特性以使其使用起来更顺畅。
1.冗长的来自flash播放器调试版本的有关策略文件事件的日志，所有关于策略文件的事件，不管是成功的还是失败的都被记录在案，我想这也有助于大家过度到这个新的更严格的版本，而且在解决相关项目部署时候失败的问题很有帮助
2.一个确定的socket主策略即端口，TCP端口843，可以参考一些默认的socket策略文件，这提供了一种为标准的socket策略文件服务的方法而不是以前系统默认的传统的选择任意端口
3.一个需要客户端通过强认证登录到本地的选项，对本地策略文件服务的socket策略文件限制可以显示的申明只有HTTPS的swf内容才能从某个指定的域链接。申明了secure="true"为以前的HTTPS策略文件而保留，这样可以使得那些混合本地和服务器端内容的应用更加安全。
由于直接的严格性变更而导致的改变
大多数的安全变更在Flash Player 9,0,115,0里初始只会产生开发者警告，一些改变可能直接导致一些swf应用程序不能和预期的那样工作，虽然我们努力使一些合法的应用不因此安全变动而受影响，但是我们不得不承认一些合法的应用也会因此受影响。
对于修复那些因为安全严格性的变更而导致的问题，我们提供了一个快速的一步一步的指导，参看对于解决问题部分，然而我们建议那些swf内容受大影响的负责人首先阅读这一部分。

恶意的策略文件：
不像我们在这篇文章里描述的其他问题一样，flash播放器对于那些恶意的策略文件并没有更新，虽然这些限制在9,0,47,0版本后被强制执行，但是从这一版本开始由这些限制导致的问题应该可以通过详细的日志得到解决。
flash播放器现在拒绝任何内容不规范的策略文件，不合法的内容可能包括：
1.前后多余内容，任何除了xml注释之外的内容不得出现在<cross-domain-policy>之前或者是</cross-domain-policy>之后，同时也要注意到这中多余的内容同时导致XML文档不合法
2.根标签非<cross-domain-policy>
3.标签内的任何文本
flash播放器出于控制改进的目的拒绝所有不合法的策略文件，恶意的策略文件可能导致部署的策略并非网站管理员所愿
Adobe现在提供xml模板文档，你可以用来校验策略文件的合法性，如果你需要的话，这些模板包括

http://www.adobe.com/xml/schemas/PolicyFile.xsd

http://www.adobe.com/xml/schemas/PolicyFileFtp.xsd

http://www.adobe.com/xml/schemas/PolicyFileHttp.xsd

http://www.adobe.com/xml/schemas/PolicyFileHttps.xsd

http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd

PolicyFile.xsd是其他策略文件的通用版本，其他的四个版本则处于各种具体的用途做了细化。
对于由于那些严格性直接导致的问题，应该按照流程来确定，你的应用是否被恶意的策略文件影响了，如果在日志里发现了恶意策略文件的记录，你应该编辑策略文件消除恶意的策略，纠正错误的拼写

域内的重定向
自从策略文件被引入之后，当策略文件被请求时候，flash播放器一直忽略策略文件，如果一个http服务器返回一个到其他域的重定向flash播放器将认为策略文件的位置为初始请求的url，即使一个请求已经将策略文件重定向到另外的服务器。策略文件的有效位置是十分重要的，因为他标志着策略文件所控制的范围——所有策略文件允许访问的资源的集合。例如一个策略文件位于http://example.com/directory1/crossdomain.xml将允许访问http://example.com/directory1/ 以及以下层次的所有资源。通常adobe不推荐重定向策略文件，因为那将使得有效的预测站点的权限变得困难
从9,0,115,0版开始，flash播放器还会接受策略文件的重定向，但是将使用最后定向的策略文件作为参考基准，而不是以前的最初策略文件，例如一个重定向到http://example.com/forks/crossdomain.xml 的策略文件将使得http://example.com/spoons/以及以下层次的资源可以访问，而 http://example.com/forks/ 这样的资源将无法访问。这也是策略文件的改进点。但是如果策略文件的初始位置被设定为有效位置，那么策略文件的存在可以通过创建一个重定向而在其他的任何位置进行模拟。通过只适用最后的位置作为有效位置，flash播放器确保只有合法的策略文件能使用。一个对策略文件的重定向只会导致策略文件重新你被装载而不是改变站点的访问许可权。
幸运的是，重定向的策略文件很少。对于任何由于严格性导致的问题，按照步骤来确定你的swf内容是否已经受到了文件重定向的影响，如果你确实从日志中找到了关于文件重定向的错误报告，（此报告本身不意味着swf内容不能像预期的那样工作），但是在后期那些被允许的行为突然被禁止的时候，这些报告可以作为线索
特别的对于/crossdomain.xml.主http策略文件位置的重定向请求会产生问题，这样做将剥夺此策略文件作为主策略文件的权利，那样这个站点将不再有主策略文件，这也会妨碍例如元策略的制定

良好的内容类型罗列
从 9,0,115,0, 版本开始flash播放器将护绿所有的不发送器内容类型以保证文件内容为text文件的HTTP策略文件，flash播放器要求内容类型应为以下：

text/* (any text type)

application/xml or application/xhtml+xml

内容类型通常是通过服务器发回来的HTTP响应头部确定的，服务器可以通过文件的类型，扩展名，位置，内容以及产生此文件的脚本等。如果你希望改变相关策略文件的内容类型那个，你可能要重新配置注册表里的文件扩展映射，或者编辑相关的服务器配置文件。可以查查服务器的配置文档。
对于那些严格性直接导致的问题，当然还是要按照流程一步一步来，要确定你的swf内容没有因为非文本内容类型而受到影响，你可以采取一系列措施来改变几个主流http服务器平台的配置，另外如果你确定你要解决的是一个和内容类型那个相关的问题，那么一定要阅读元策略一章，因为一个通常的办法就是选择一个元策略来解决特别的内容类型以及text、跨域策略。这样做通常能一举两得，创建一个元策略同时解决策略非文本类型带来的问题
flash播放器要求文本格式的内容类型也是对安全性的改进之一，一个非文本内容的策略文件通常表示网站的管理者并没有将其视为策略文件。
当flash播放器在浏览器内运行的时候，许可的内容类型那个依赖于flash播放器对浏览器的网络栈的检测，最新的浏览器才支持这项功能，而一些老的浏览器并不支持，那些不支持的浏览器的名单可以参看附录A，如果flash播放器发现他不能那个检测内容类型，那么他会产生一个警告日志，同时策略文件也会被忽略检查同时接受，甚至他们根本就没有内容类型

直接更严格的socket通信
从901150版本开始，flash播放器为socket策略文件制定了更加严格的规则，socket策略文件链接到socket服务器，认证as语言产生的链接。在这一部分将详细的讨论这些更加严格的限制，简单的说，要创建socket连接就要提供socket策略文件，前述的版本允许swf文件通过在自己的域上创建高数值得端口而不需要socket策略文件。并且允许任何的swf内容通过http策略文件链接到这些端口而不受限制，现在随着更加严格的socket策略规则的制定，这些都被禁止了。
对于大多数的socket服务器，更严格的规则将在两个阶段实现，第一阶段只产生警告（除非主机显式的要求新规则），然而对于一些特殊的规则即使在第一阶段他们也将立即被采用。如：
1.在本地定义的socket除了那些被定义为（localhost，即那些被定义为回路的如IPV4中的127.0.0.1和IPV6中的：：1）的，以及那些内部地址被分配外部地址的（例如那些被分配以太网地址适配的），这些规则形成了flash播放器的DNS强化策略。系统对强socket规则的可选对服务器主机来说是恰当的，但是对于本地的机器大多数用户不视为服务器的来说则并不合理，这些规则帮助避免了潜在的dns重定向攻击，而对于localhost则不在此列，因为不太有可能有服务器的域名为localhost

2.本地连接的ip地址，除了那些带local的外，本地连接IP通常是那些只分配给单个链接的，一个网段例如网络连接的点对点连接。本地连接通常用于那些0配置的P2P网络，如ipv4里的169.254.*，以及IPV6里的 fe80:*，这种情况和上面的本地情况很累系，而排出的.LOCAL则反映了很少有服务器有域名为local的。

3.端口为1024以上的socket链接用来服务其自己的策略文件，而且并不列出其域的策略文件，这不是一个单独的规则，这是由于系统采取更加严格的socket规则带来的，任何服务于其自己的socket策略文件更新为采用新的严格策略，如果一个swf文件视图连接同一个域下的旧规则的socket（策略文件不必须）然而在新的严格策略下，socket策略文件则是必须的，如果刚好socket策略文件不在自己的域上，来自同一个域的swf也无法进行时哦创可贴链接
对于所有因严格性变更而导致的问题，按照步骤进行排除，以确定他是否是由此导致的，然后采取措施来弥补这些问题。