原始来源——http: //my.safaribooksonline.com/book/networking/security/9780596806309/inside-out-attacks-the-attacker-is-the-insider/content_ownership

2.4.1。滥用 Flash 的 crossdomain.xml

同源策略通常被认为过于严格，导致应用程序开发人员要求两个不同的域能够相互交互工作。最早支持这种跨域交互的流行浏览器插件之一是 Adob​​e 的 Flash。Adobe 了解允许任意跨域访问的危险，并实施了一项安全措施来确定 Flash 是否允许跨域交互。这种安全措施是通过跨域策略文件实现的。

Flash 的跨域策略文件定义了跨域交互的“规则”。跨域策略文件只是一个名为 crossdomain.xml 的 XML 文件。下面是一个 crossdomain.xml 文件的示例：

<?xml version="1.0" encoding="UTF-8" ?>

<cross-domain-policy
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
    xsi:noNamespaceSchemaLocation=
    "http://www.adobe.com/xml/schemas/PolicyFile.xsd">

    <allow-access-from domain="*" /> </cross-domain-policy>

此 crossdomain.xml 策略文件必须托管在希望允许跨域交互的服务器上。在允许跨域交互之前，Flash 将检查目标域上是否存在跨域策略文件。如果不存在策略文件，Flash 默认使用限制性同源策略，不允许跨域交互。如果目标域上存在 crossdomain.xml 文件，Flash 会读取策略文件中包含的“规则”，并允许基于已建立的规则进行跨域交互。再一次，整个前提是基于必须从希望允许跨域交互的域提供跨域策略文件这一事实。默认情况下，Flash 将检查 Web 应用程序的 Web 根目录 (http://www.example.xml) 中是否存在名为 crossdomain.xml 的跨域策略文件。

loadPolicyFile()从 Flash 7 开始，当 Flash 组件以 URL 作为参数（包含目标服务器上的 crossdomain.xml 的位置）调用时，您可以在任意位置（不仅仅是 Web 根的根）进行 Flash 检查 crossdomain.xml ）。

笔记

System.Security.loadPolicyFile()您可以在以下网站上找到更多信息：

http://livedocs.adobe.com/flash/mx2004/main_7_2/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Flash_MX_2004&file=00001098.html

Flash 的跨域策略的概念基于几个简单的前提。简化版的逻辑如下：

跨域策略文件必须位于 Web 服务器的 Web 可访问路径中，以允许从 Flash 跨域访问该服务器。

某人可以将任意文件放入 Web 服务器的 Web 可访问路径的唯一方法是，如果他具有对 Web 服务器的管理访问权限。

因此，如果 Web 服务器在 Web 服务器上的 Web 可访问路径中具有跨域策略文件，则管理员必须将其放置在那里。

这种逻辑本质上是有缺陷的，因为许多 Web 应用程序允许用户将内容上传到 Web 服务器。如果应用程序随后在其域名下提供该内容，则该 Web 应用程序在不知不觉中将自己置于风险之中，因为 Flash 的跨域能力。如果攻击者能够上传 crossdomain.xml 策略文件，则攻击者可以在其 Web 服务器上使用恶意 Flash 小程序来攻击易受攻击的应用程序。这个邪恶的 Flash 小程序将能够向易受攻击的 Web 应用程序发出跨域请求，并且这些请求将使用碰巧偶然发现攻击者网站的任何不幸用户的会话 cookie 发出。更糟糕的是，跨域策略文件不需要具有 .xml 扩展名。Flash 的安全标准将尊重任何文件扩展名。

笔记

Adobe Flash 9.0.115.0 允许规范“元策略”。这些策略定义应该遵守服务器上的哪些策略文件。您可以在http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_03.html找到有关元策略的更多信息。

这里的一切都取决于您的 Flash Player 的版本。这是一个东西列表，你应该在这个 .swf 文件上尝试一下。

我们的第一个猜测是跨站脚本，所以我们应该尝试一下 XSS，尤其是我们注意到其中一个不安全的方法：loadMovie.

跨站脚本

有几种类型的不安全函数。他们每个人都有不同的有效载荷：

• getURL - 有效载荷： javascript:alert('XSS')
• load*（在这种情况下：） loadMovie- 有效负载：asfunction:getURL,javascript:alert('XSS')[ asfunction在此上下文中工作，直到发布 Flash Player 9 r48]
• TextField.htmlText - 有效负载：<img src='javascript:alert("XSS")//.swf'>[.swf 在这里非常重要 - 其他扩展不会绕过 Flash Player 的内部过滤器]。

跨站闪烁

我们的第二个猜测应该是XSF。第一个 Flash 电影尝试加载第二个。当它获得对沙箱同一部分的访问权时，我们很容易受到 XSF 的攻击。这意味着，我们能够加载外部的、邪恶的 flash 文件，这可能导致 XSS 或假 flash-movie（例如：fake flash-form，一种网络钓鱼）。现在让我们想一想我们什么时候可以得到这些缺陷。

Flash Player 7 或更高版本仅允许在同一域之间执行跨域脚本。我们可以从不同的域加载 .swf 文件，但这些文件将无法交换数据。有关更多详细信息，您应该检查System.security.allowDomain。

现在让我们谈谈：

允许脚本访问

此参数可以在内部param或embed标记中找到，它决定了从 SWF 文件中执行出站 URL 访问的能力。有三个可能的值： - sameDomain：当 .swf 文件和嵌入的 HTML 页面在同一个域中时，允许访问通信。- always：与 相同sameDomain，但 .swf 文件也可以与来自不同域的 .swf 进行通信（而不是嵌入）。- never- .swf 文件无法与任何页面通信。应用层协议、域名和端口号定义了来源。当 .swf 文件从浏览器获取要执行的 JavaScript 代码时，它将在嵌入网站的原点内执行。让我们考虑两种情况[ allowScriptAccess = sameDomain]：

• A.com 上托管的 .swf 嵌入在 B.com 上的 HTML 网站中： origin: B.com
• B.com 有一个iframe从 A.com 加载的 .swf 文件：origin: A.com

默认值设置为sameDomain。这意味着没有AllowScriptAccess属性的.swf 应该被视为有sameDomain属性的.swf。2008 年已经注意到，这sameDomain可能导致跨站请求伪造。我真的建议您阅读有关此的博客文章（更多详细信息 - 此处）并查看PoC。

您不应该忘记 Flash 参数污染。

Flash参数污染

不是每个 .swf 文件都可以在没有原始 HTML 的情况下加载。如果程序员忘记了清理，我们可以将全局变量注入闪存：

print '<object type= (...) data="'.$_GET['flash'].'"></object>'

URI: http://example.com/?flash=flash.swf?var=bum

HTML: <object type= (...) data="flash=flash.swf?var=bum"></object>