Flash Player 8 中的安全性更改
要求
用户级别
中级
Macromedia 已更改了 Flash Player 8 中应用于本地 Flash 内容的安全模型。默认情况下, 从用户本地文件系统而不是通过 HTTP 运行的 Flash 应用程序在 Flash Player 8 中的权限比在 Flash Player 7 中具有更多限制。该模型适用于所用版本的 Flash 内容, 这意味着除 Flash Player 8 发行之后创建的新内容外, 在此版本之前发布的内容也可能会受到影响。本文描述如何修复因这些更改而导致的大多数问题。
除了更改安全模型外, Flash Player 8 还引入了其它一些限制并添加了一些新的安全功能。本文还描述了那些更改, 但是在 Flash Player 8 中, 本地安全更改是到目前为止最大的安全主题。
注意: 这些本地安全更改不会影响通过 HTTP 提供的 Flash 内容。大多数 Flash 内容都通过 HTTP 提供, 因此不会受到这些更改的影响。
新的限制
下面是有关 Flash 内容可执行功能的最新限制:
- 本地沙箱: 默认情况下, 本地 SWF 无法再连接 Internet、执行 HTTP 通信或与本地 HTML 文件通信。如果版本 7 或更低版本的 SWF 尝试执行其中任一操作, 用户将会看到一个警告对话框, 通知他们无法执行该操作。最终用户或 Flash 开发人员可以通过设置适当的权限来消除此对话框并解除现有内容中的故障。
- 加载限制: 来自非本地 URL 的 SWF 和 HTML 内容无法再加载来自本地路径的任何内容 SWF、HTML、PNG 等 。
- 第三方存储: Flash Player 用户现在可以阻止第三方 SWF 来自浏览器地址栏中显示的域以外的域 读取或写入永久共享对象。默认情况下不应用此限制；用户必须主动选择是否应用它。
- allowScriptAccess 的默认值: 对于版本 8 或更高版本的 SWF, HTML allowScriptAccess 参数的默认值是“sameDomain”而不是“always”。这不影响版本 7 或更低版本的 SWF。allowScriptAccess 参数控制 SWF 是否可以调用 HTML 页中的 JavaScript。
新的安全功能
下面是适用于 Flash 内容的新安全功能 有关 Flash Player 7 的安全信息, 请参阅 Macromedia Flash Player 7 中的安全性更改 :
通配符 allowDomain: System.security.allowDomain 现在接受“*”通配符参数, 该参数允许 SWF 从任意域进行访问。
更精确的权限: System.security.allowDomain 和 System.exactSettings 现在仅适用于调用它们的 SWF, 而不是调用 SWF 的整个域。这仅影响新的 版本 8+ 内容, 因此保留了向后兼容性。
安全的永久共享对象: 通过 HTTPS 加载的 SWF 现在可以创建 SharedObject 对象, 该对象只能由同样通过 HTTPS 加载的 SWF 访问。这样将反映出浏览器 Cookie 的功能, 并帮助共享对象中存储的数据免遭搜寻和修改的威胁。现有共享对象不受影响。
为什么要更改本地安全性？
Flash Player 8 中的本地安全性更改主要出于下面一个原因: 当用户将 SWF 下载到计算机上时, 他们应能够确信 Flash Player 不会允许这些 SWF 对他们实施任何有害行为。无论何处考虑到安全性, 用户在计算机上下载和运行 SWF 文件时应感觉像是存储 JPEG 或 TXT 文件那样自信, 而不是像下载和运行可执行文件那样需小心谨慎。
在 Flash Player 7 之前, 对本地 SWF 的处理取决于本地 SWF 对 Flash 内容的作者意味着什么: 本地 SWF 通常只是一个临时的本地文件, 该文件最终将发布到网页上。在这种情况下, 不需要限制本地 SWF 可以执行的操作。但是, 当下载和运行 SWF 的用户不是 Flash 作者时, 该用户可能无法充分了解 SWF 的来源以确定其是否有恶意。在 Flash Player 7 及较早版本中, 如果某个恶意方设法让某用户下载并运行 SWF, 则本地 SWF 将能够合并两个权限而造成不良后果: 它能够使用诸如 XML.load 之类的函数从用户的文件系统中的已知 或猜测的 位置读取文本文件, 然后将这些文件内容发送回攻击者。此类文件嗅探模式正是 Flash Player 8 中的本地安全更改所要防止的。
Flash 长期成功的一个巨大因素是所有新发布的 Flash Player 版本具有向后兼容所有现有 Flash 内容的趋势。安全性更改有时会违反这个原则, 这为 Flash 开发人员和类似用户带来了不便。 许多读者可能想起了 Flash Player 7 中的安全性更改 所需的内容更改。 Macromedia 意识到这种更改对于客户的影响, 因此我们不轻易进行此类更改。如果这种更改影响到您, 我们对此表示诚挚的歉意。
尽管存在上述挑战, 但是对于像 Flash 这样的平台技术改进安全模型是正确的方向。Flash Player 拥有难以置信的销量, 对客户来说, 这也是 Flash 价值的重要部分。如果希望用户和企业继续安装和升级 Flash Player, 安全行为是一个必备条件。现在看来, 如果在 Flash Player 的早期版本中针对本地 Flash 内容设计一套更安全的规则, 事情就会容易得多。但是, 就像我们的客户对 Flash 的使用一样, 安全威胁也在不断发展, 因此有时需要发布多个版本才能解决问题。
一个好消息是, Flash Player 8 中的更改对内容的影响远远少于 Flash Player 7 中的更改对内容的影响。Flash Player 7 中的更改影响部署在网页中的一些内容, 而在 Flash Player 8 中的更改仅影响作为本地文件部署的“不太普遍”的内容。随着 Flash 在全球数以百万计的发展, “不太普遍”仍然意味着还有大量本地部署的 Flash 内容示例, 但是我们希望相对于 Flash Player 7 更改而言, 此次开发人员受到更改的影响更少。
本地安全性基础知识
在 Flash Player 7 和更早版本中, 可以自由允许本地 SWF 使用本地路径从用户的文件系统加载 执行通常要受到 Flash Player 安全准则制约的大多数操作。例如, 默认情况下, 尽管只允许通过 HTTP 加载的 SWF 使用 XML.load 从自己的原始域加载文本, 但允许 Flash Player 7 中的本地 SWF 使用 XML.load 从任何 HTTP URL 或任何本地文件系统路径加载文本。
我们把从本地路径读取文本文件的权限称为本地读取。同时, 在 Flash Player 7 中, 所有 SWF 都有一个称为网络发送 的附加权限, 在此权限下, 通过 LoadVars.send 执行 HTTP POST 之类的操作可以将任何数据发送到任意 Internet 位置。结合最终用户从不受信任源下载的本地 SWF 中的本地读取和网络发送, 您可以看到本地 SWF 能够采用不适当的步骤从用户计算机读取文本文件, 并将其内容发送回 Internet 上的某个位置, 所有这些都是在用户不知情的情况下进行的。
在 Flash Player 8 中, 本地 SWF 的安全规则简单摘要如下: 默认情况下, 本地 SWF 将保留本地读取权限但会丢失网络发送权限；并且不允许以任何方式与 Internet 或任意 HTTP 服务器 通信。通过在 SWF 文件中更改设置, Flash 作者能够选择让 SWF 获得网络发送权限, 并因此放弃本地读取权限。最终, 作者和用户能够配置 Flash Player, 将 SWF 提升到受信任 状态, 使其具有两种权限, 换句话说, SWF 将具有它在 Flash Player 7 中的权限。
什么将受到影响
Flash 内容是否受影响取决于两个因素: 是否为本地内容以及所执行的是哪种类型的 Flash Player。
受影响的 SWF 是那些从本地路径加载的 SWF。它包括下列 URL 形式 只列出其中一部分 的示例:
- c:\temp\my.swf
- file:///c /temp/my.swf
- /temp/my.swf
- file:///temp/my.swf
- \\server\share\my.swf
- file:////server/share/my.swf
- 通过本地 SWF 加载的相对 URL
存在很多不同的 Flash Player 类型, 并且每种类型都会在不同的环境下受到影响。
- 无论何时在 Web 浏览器中使用 Web 浏览器播放器 ActiveX 控件和插件播放器 , 都会强制使用本地安全规则。
- 在非浏览器应用程序中使用时, Web 浏览器播放器不会总是强制使用本地安全规则。如果您使用的是一个在其中嵌入某个播放器的应用程序, 请参见“Flash Player 嵌入和本地安全性”一节。
- 独立播放器强制使用本地安全规则。
- Flash 放映文件可以由 Macromedia Flash 创作应用程序和独立播放器创建, 它不会强制使用本地安全规则。这是因为它们都是可执行应用程序, 用户通常必须谨慎对待。
- Flash 中的创作播放器不会强制使用本地安全规则, 因为它们仅用于测试正处于开发中的内容, 不会播放网页中的内容。
沙箱类型
在 Flash Player 8 中, 所有 SWF 以及 HTML 文件,用于 SWF-HTML 脚本处理 都放在以下四类沙箱之一中:
- 远程沙箱。来自非本地 URL 的所有文件都放在远程沙箱中。有很多此类沙箱, 对于从中加载文件的每个 Internet 或 Intranet 域都提供一个这样的沙箱。这些沙箱与 Flash Player 6 中引入的相同；在 Flash Player 8 中未作更改。
- 供文件系统使用的本地沙箱。这是 Flash Player 8 中默认的本地文件沙箱。该沙箱中的 SWF 不能以任何方式连接 Internet 或任何 HTTP 服务器 , 例如, 它们不能将 HTTP URL 传递到 loadMovie 、getURL 或 XML.load 中。因为在 Flash Player 7 中允许此类操作, 所以, 如果版本 7 或更早版本的 SWF 尝试连接 Internet, 而当最终用户从 Flash Player 7 升级到 Flash Player 8 后, 将会出现以前正常工作的内容可能如期关闭的情形。因此, 当版本 7 或更早版本的 SWF 尝试连接 Internet 时, Flash Player 8 将会显示一个警告对话框, 以提示用户连接 Internet 的尝试失败。警告对话框包含一个允许用户访问“设置管理器”的按钮, 在这里他们可以选择将受影响的内容提升到本地受信任状态 请参见下文 。
- 供网络使用的本地沙箱。此沙箱中的 SWF 可以通过 HTTP 进行通信, 但不能从本地文件系统读取。任何版本的 SWF 都可以使用 SWF 本身设置的标记选择此沙箱, 换句话说, 不需要任何用户操作就可以将 SWF 放置到此沙箱中。在 Flash 8 中, 该标记可以使用发布选项设置, 或者使用 Local Content Updater 本地内容更新程序 设置, 后者是 macromedia.com 提供的一个免费的 SWF 后处理实用程序。
- 受信任的本地沙箱。该沙箱不受限制。它提供与 Flash Player 7 中所有本地文件相同的打开权限。如果最终用户给出授权, 任何本地文件都可以放在该沙箱中。该授权可以有两种形式: 通过设置管理器以交互方式授权, 或通过可执行安装程序在用户计算机上创建 Flash Player 配置文件的非交互方式授权。
查看描述本地安全的图表附录对此会很有帮助 请参见本地安全示意图一节 。
如果本地 SWF 需要访问 Internet 或 Intranet HTTP 服务器 , 有两种本地沙箱提供这种访问。供网络使用的本地沙箱更容易获得, 并且所有必需的配置可在 SWF 本身中方便地传播。受信任的本地沙箱更为强大, 它提供更大的权限, 但是通常需要花费更多努力才能获得, 并且需要独立于 SWF 本身的配置信息。在解释了本地安全规则详情后, 本文将返回到如何在这两个沙箱之间进行选择的问题。
全局权限
因为本地文件在 Flash Player 8 中不再具有不受限制的权限, 因此存在可以将 Flash 权限授予本地文件的情形。这些内容将在下一节中介绍。
通常, Flash Player 遵循要求全局权限 的原则是为了授予本地文件权限。例如, 如果远程 SWF 想要通过供网络使用的本地 SWF 允许对其自身进行脚本处理, 它必须调用 System.security.allowDomain "*" , 从而允许其它任何加载的 SWF 对它进行脚本处理。Flash Player 不会以任何方式只对本地文件授予权限；授权方必需要对所有 文件授予权限。这是因为 Flash Player 不能确定任何本地文件的来源—该文件可能来自任何地方。因此, 允许本地文件执行操作是不合适的, 除非授权方不在意文件的来源。
请不要调用 System.security.allowDomain "*" , 除非执行此操作的 SWF 不包含敏感信息。不要简单地认为调用 System.security.allowDomain "*" 可以解决所有安全问题, 这样做会牺牲掉内容所需的保护！请在每次授予全局权限时考虑一下这样做的后果。
本地沙箱
本节描述放置 SWF 的各种本地沙箱。
权限
Flash Player 为本地文件定义了以下权限类型:
- 本地读取。该权限适用于供文件系统使用的本地 SWF, 但不适用于供网络使用的本地 SWF。它包括将数据从外部文件加载到 ActionScript 变量的操作, 此处的数据来自位于本地文件系统中的文件。本地 URL 形式的示例在前面的“什么受到影响”一节中给出。受影响的数据加载操作如下所示:
- XML.load、XML.sendAndLoad
- LoadVars.load、LoadVars.sendAndLoad、loadVariables、loadVariablesNum、MovieClip.loadVariables
- 从另一个 SWF 库中导入元件
- 网络发送。该权限适用于供网络使用的本地 SWF, 但不适用于供本地文件系统使用的本地 SWF。该权限包括将数据或请求发送到 Internet 位置或 HTTP 服务器的操作。这包括以下所有与非本地 URL 一起使用的操作:
- XML.load、XML.send、XML.sendAndLoad
- LoadVars.load、LoadVars.send、LoadVars.sendAndLoad、loadVariables、loadVariablesNum、MovieClip.loadVariables
- XMLSocket.connect
- NetConnection.call (Flash Remoting)
- 从另一个 SWF 库中导入元件
- getURL、MovieClip.getURL
- loadMovie、loadMovieNum、MovieClip.loadMovie、MovieClipLoader.loadClip
- Sound.loadSound
- 网络读取。供网络使用的本地 SWF 可执行网络发送操作。一些网络发送操作属于单向操作, 仅发送数据而不返回答复；但其它网络发送操作是能够收到回复的请求。后一种操作称为网络读取 操作 － 即网络发送操作的超集。虽然需要从数据的原始域获得权限, 但是供网络使用的本地 SWF 仍会尝试网络读取操作。以下是使用非本地 URL 的操作:
- XML.load、XML.sendAndLoad
- LoadVars.load、LoadVars.sendAndLoad、loadVariables、loadVariablesNum、MovieClip.loadVariables
- XMLSocket.connect
- NetConnection.call (Flash Remoting)
- 从另一个 SWF 库中导入元件
- SWF-HTML。这包括允许 SWF 文件处理 HTML 文件脚本的操作, 反之亦然。由于 Flash Player 和网页浏览器之间的安全模式可能不匹配, 因此在三个本地沙箱中只有受信任的本地文件具有 SWF-HTML 权限。这些操作包括:
- SWF 到 HTML 的操作:
fscommandgetURL("javascript:...")ExternalInterface.call
- HTML 到 SWF 的操作:
JavaScript API SetVariable、GotoFrame 等
调用使用 ExternalInterface.addCallback 建立的回调
将 SWF 选入供网络使用的本地沙箱
如果此沙箱包含称为 UseNetwork 的标记, 那么本地 SWF 将会放置在该沙箱中。虽然该标记只对 Flash Player 8 和更高版本有意义, 但是该标记仍然可以放置在任何版本的 SWF 中。该标记可以使用两种方式之一建立:
- 当从 Flash 8 发布时, 在“发布设置”对话框中, 选择 Flash 选项卡, 在底部找到“本地回放安全性”选项, 并选择“只访问网络” 见图 1 。
- 如果您没有 Flash 8 或想要在发布后使用 SWF 工作, 您不必重新发布它们, 而可以使用 Flash Local Content Updater, 它是 macromedia.com 上可供下载的免费命令行实用工具。Local Content Updater 可添加、删除或检查在一个或多个 SWF 上操作的 UseNetwork 标记。Local Content Updater 可用于 Windows、Mac OS X 和 Linux, 并且也可作为源代码使用。
注意, UseNetwork 标记不会影响通过 HTTP 加载的 SWF (这些标记始终放在远程沙箱中)或者放置在用户信任的本地沙箱中的 SWF (它们始终放在受信任的本地沙箱中)。UseNetwork 标记只影响以其它方式放置在供文件系统使用的本地沙箱中的 SWF。
将文件配置到受信任的本地沙箱
如果某本地 SWF (或 HTML 文件)放置在用户的本地配置中指定为受信任的本地路径下, 那么该本地 SWF (或 HTML 文件)将放置在该沙箱中。如果到单独文件的路径或目录是可信任的, 那么每个所选目录和及其任何子目录的所有文件都是可信任的。信任指派可通过两种方式完成:
- 设置管理器。用户可以访问设置管理器的安全面板并且手动添加、编辑或删除列表中受信任的路径 (见图 2)。
- 用户也可能使用该面板中的“询问/允许/拒绝”选项做出 Flash Player 如何处理旧的 SWF 版本 7 和更低版本的供本地文件系统使用的 SWF 的全局决定。这里的默认值是“询问”, 除了显示警告对话框外, 它将放弃任何已禁止的操作。改为选择“始终允许”将允许已禁止的操作继续进行, 因而回复到 Flash Player 7 的默认行为。但是, 该设置不会影响版本 8 或更高版本的 SWF, 它只会影响在较新的本地规则产生前已开发的内容。选择“始终拒绝”会导致所有已禁止的操作失败, 且不显示对话框。
注意: 询问/允许/拒绝选项不仅管理本地安全提示情形, 而且管理自 Flash Player 7 以来出现的精确域匹配提示情形。
- FlashPlayerTrust 配置文件。这些是列出受信任路径的简单文本文件。这些文件由可执行的安装程序创建。当安装程序将 SWF 安装到用户的计算机时, 它能够安装信任的配置文件并指定 SWF 是受信任的。当该做法没有表现用户显式决定每个受信任的 SWF 时, 该用户已通过运行安装程序将信任隐式给予它, 毕竟它是可执行程序。Flash Player 可识别以下两个位置的信任配置文件: 影响计算机所有用户的位置和只影响当前用户的位置。所有用户位置需要操作系统级别的管理权限。这些位置如下: >
- Windows 所有用户:
<系统 › \Macromed\Flash\FlashPlayerTrust
例如 c:\WINNT\system32\Macromed\Flash\FlashPlayerTrust
- Windows 单个用户:
<应用程序数据 › \Macromedia\Flash Player\#Security\FlashPlayerTrust
例如 c:\Documents and Settings\fred\Application Data\Macromedia\Flash Player\#Security\FlashPlayerTrust
- Mac OS 所有用户:
<应用程序支持 › /Macromedia/FlashPlayerTrust
例如 /Library/Application Support/Macromedia/FlashPlayerTrust
- Mac OS 单个用户:
<应用程序数据 › /Macromedia/Flash Player/#Security/FlashPlayerTrust
例如 /Users/fred/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust
- Windows 所有用户:
这些位置是目录, 不是单个文件。可以将任意数目的配置文件安装在这些目录中；Flash Player 将读取查找到的所有文件。不能将配置文件放置在 FlashPlayerTrust 的子目录中；必须直接放在 FlashPlayerTrust 目录中。可以任意命名独立配置文件, 为避免命名冲突, 安装程序应以特定于产品的方式命名这些配置文件。FlashPlayerTrust 目录不一定在任何给定系统中都存在, 因此安装程序需要创建它们。
这些文件的语法很简单: 它们包含任意数量的本地路径, 每行一个。允许空格和空行。可以包含带有 # 字符的注释；这些注释位于一行的末尾。对于包含空格的路径, 不需要使用引号 否则会导致问题 。
这些文件包含文件系统路径, 它们在一些用户的计算机上可能包含非 ASCII 字符, 因此在 FlashPlayerTrust 文件中使用的文本编码很重要。Flash Player 将在这些文件的开始处查找 Unicode 字节顺序的标记字符, 并识别 UTF-8 和 UTF-16 字节顺序标记, 并相应地将其余的文件视为 UTF-8 或 UTF-16。 例如 Windows Notepad 和 Mac TextEdit 可以写入包含这些字节顺序标记字符的 Unicode 文本文件；许多其它文本编辑器也可以。 如果 Flash Player 在 FlashPlayerTrust 文件开始处未找到字节顺序的标记字符, 它将使用计算机的当前“代码页” 默认为本地编码 解释文件。
HTML 沙箱
我们通常提到放置在沙箱中的 SWF, 为了控制 SWF-HTML 交互操作, Flash Player 同样将 HTML 文件放置在沙箱中。本地 HTML 文件只有两个沙箱: 受信任沙箱和不受信任沙箱。默认情况下, 本地 HTML 文件是不可信的, 并可以采用与 SWF 相同的方式指定为受信任的。本地 HTML 文件的沙箱只对 HTML-to-SWF 的脚本处理重要 如使用 Flash Player JavaScript API 。
确定 SWF 的沙箱
使用以下只读 ActionScript 属性, SWF 可确定自己的沙箱类型:
System.security.sandboxType
该属性具有下列四种字符串值之一:
- "remote"
- "localWithFile"
- "localWithNetwork"
- "localTrusted"
供文件系统使用的本地沙箱行为
供本地文件系统使用的沙箱中的 SWF 可执行本地读取操作, 但是不会执行网络发送或 SWF-HTML 操作。
如果使用 Flash Player 的调试版本, 并连接到 Macromedia Flash 中的调试器, 则当此沙箱中的 SWF 尝试某个已禁止的操作时, 您将在描述失败操作的输出面板上看到诊断信息。
当用户播放此沙箱中发布版本为 7 或更早版本的 SWF, 并且 SWF 尝试某个已禁止的操作时, 将会显示一个安全警告对话框, 指示由于 Flash Player 8 的本地安全规则的更改, 内容可能已经如期停止工作 见图 3 。
每次运行程序时, 此对话框最多出现一次, 后续操作将不会触发它, 而是在没有任何提示的情况下失败。
无论用户在对话框中采取什么操作, 尝试的操作都将失败。但是, 如果用户单击“设置”按钮, 将打开一个显示设置管理器的新窗口, 此处用户可选择信任那些尝试已禁止操作的本地内容。如果用户选择“设置管理器”中的“添加位置”命令, 并在短时间内查看图 2 中的“Flash Player 设置管理器”, 就会显示曾经尝试已禁止操作的本地 SWF 路径的提示 (见图 4)。
用户可选择仅将该路径复制到“信任此位置”文本框, 从而信任可触发此对话框的单个 SWF。有时候这就足够了；但是, 有时某个应用程序是由多个文件组成的, 并且为了使应用程序如期运行, 有必要信任多个文件。 请参见后面介绍协作介质的部分。 因此, 用户必须试验信任多个文件或包含可触发此对话框的 SWF 的完整目录。
如果用户在“设置管理器”中进行更改, 在更改生效前, 就必须重新启动原始应用程序 通常通过刷新浏览器 。
围绕设置管理器的安全面板的文档向最终用户解释了以上工作流程。要获得有关信任本地内容的分步说明, 用户也可以访问技术说明: 如何让本地 Flash 内容与 Internet 通信？。
FlashAuthor.cfg
对于最终用户, 本地安全警告对话框只对版本 7 和更早版本的 SWF 显示。此对话框可让用户修复受新的本地安全性规则影响的 Flash 8 以前的内容。
但是, 对于 Flash 内容的作者, 安全警告对话框可能是失败原因的有用指示器。无论任何版本的 SWF 尝试被本地安全规则禁止的操作时, 作者都希望立即得到通知。
为了支持这种需要, 各种 Macromedia 创作工具 包括 Macromedia Flash 8 都安装了一个称作 FlashAuthor.cfg 的文件, 指示当由任何供本地文件系统使用的 SWF 无论任何版本 执行被禁止的操作时 Flash Player 将显示警告对话框。而且任何用户都可以自由创建这个文件。可以将该文件放置在以下两个位置中的任何一个, 每个位置都与 FlashPlayerTrust 目录平级:
- Windows 所有用户:
<系统 › \Macromed\Flash\FlashAuthor.cfg
例如 c:\WINNT\system32\Macromed\Flash\FlashAuthor.cfg
- Windows 单个用户:
<应用程序数据 › \Macromedia\Flash Player\#Security\FlashAuthor.cfg
例如 c:\Documents and Settings\fred\Application Data\Macromedia\Flash Player\#Security\FlashAuthor.cfg
- Mac OS 所有用户:
<应用程序支持 › /Macromedia/FlashAuthor.cfg
例如 /Library/Application Support/Macromedia/FlashAuthor.cfg
- Mac OS 单个用户:
<应用程序数据 › /Macromedia/Flash Player/#Security/FlashAuthor.cfg
例如 /Users/fred/Library/Preferences/Macromedia/Flash Player/#Security/FlashAuthor.cfg
此文件中当前只有一个可识别指令:
LocalSecurityPrompt=Author
当决定是否在图 3 中显示警告对话框时, 该指令可导致 Flash Player 忽略 SWF 版本。
FlashAuthor.cfg 还可包括空格和通过 # 字符指示的注释, 注释一直延伸至行的末尾。
如果您要开发作为本地文件播放的 SWF 内容, LocalSecurityPrompt=Author 指令可能不符合您的需要, 因为它阻止 Flash Player 完全模拟最终用户的行为。您可以通过将 FlashAuthor.cfg to 内容更改为除上面所示的 LocalSecurityPrompt=Author 以外的任何内容来禁用作者指定的行为。例如, 您可以注释掉上面的行, 或者将它更改为容易理解的内容, 如:
LocalSecurityPrompt=User
注意, Macromedia Flash 8 将在所有用户和单个用户两个位置安装 FlashAuthor.cfg。当两个位置都显示 FlashAuthor.cfg 时, Flash Player 将在单个用户位置兑现副本, 因此确保要编辑单个用户文件。
供网络使用的本地沙箱行为
供网络使用的本地沙箱中的 SWF 可执行网络发送操作, 但是不能执行本地读取或 SWF-HTML 操作。
如果使用 Flash Player 的调试版本, 并连接到 Flash 中的调试器, 则当此沙箱中的 SWF 尝试某个已禁止的操作时, 您将在描述失败操作的输出面板上看到诊断信息。
此沙箱中的 SWF 不会引起安全警告对话框的显示, 因为在本地安全规则更改前, 不存在已生成内容, 而是依然存在于供网络使用的本地沙箱中。从最终用户的角度看, 此沙箱中所有已禁止的操作都将失败且无任何提示。
供网络使用的本地 SWF 可执行网络发送操作。一些网络发送操作属于单向操作, 仅发送数据而不返回答复；但其它网络发送操作是能够收到回复的请求。后一种操作称为网络读取 操作 － 即网络发送操作的超集。网络读取操作的一个示例是 XML.load "http://mysite.com/data/schedule.xml" 。允许供网络使用的本地 SWF 尝试网络读取操作。但是, 为遵守 Flash Player 的全局权限原则, 以便供网络使用的本地 SWF 可以从给定域中加载数据, 该域必须提供一个策略文件, 该文件授权所有域读取相关数据和声明 <allow-access-from domain="*" / › 。在以上示例中, mysite.com 需要位于默认位置 http://mysite.com/crossdomain.xml 或靠近所需数据 http://mysite.com/data/crossdomain.xml 的策略文件。在后一种情况中, 为了通知 Flash Player 非默认的策略文件位置, 加载的 SWF 需要调用以下文件:
System.security.loadPolicyFile("http://mysite.com/data/crossdomain.xml")
协作介质的本地安全性
到目前为止, 我们已经从单个 SWF 操作本身的角度讨论了本地安全性: 在用户未授权的情况下, 单个 SWF 不会同时具有本地读取和网络发送两种权限。但是当多个 SWF 彼此协同工作时, Flash Player 8 中的本地安全增强功能还必须能够保护 Flash Player 用户。SWF 的协作集 不能同时拥有本地读取和网络发送两种权限。
在 SWF 之间完成协作需要两个步骤。首先, 一个 SWF 必须加载另一个 通常使用 ActionScript loadMovie 命令 。其次, 两个 SWF 必须交换信息 可使用 ActionScript 变量、方法调用、LocalConnection 对象等 。这种信息交换有时被称为跨域脚本处理。
为维护本地安全, Flash Player 在某些情况下会禁止 SWF 的加载, 有时它允许加载 SWF 但是限制跨域脚本处理。
在位于相同沙箱的 SWF 之间将始终允许 SWF 加载和跨域脚本处理。例如, 任何供文件系统使用的本地 SWF 都可以加载其它任何供文件系统使用的本地 SWF, 并可以对它进行跨域脚本处理；任何供网络使用的本地 SWF 都可以加载其它任何供网络使用的本地 SWF, 并可以对它进行跨域脚本处理等。当来自不同沙箱的两个 SWF 尝试协作时, 将会显示限制。
表 1 总结了沙箱之间的加载和跨域脚本处理的限制, 其后显示各个规则。SWF 之间的任何协作都有两部分。我们将启动协作的 SWF 调用 loadMovie 或执行跨域脚本处理 称为访问 SWF, 将另一 SWF 称为被访问 SWF。该表顶部的标签表示访问 SWF 的沙箱, 左边的标签表示被访问 SWF 的沙箱。
| 被访问 SWF 的沙箱 | 供文件系 统使用的 本地沙箱 |
供网络 使用的 本地沙箱 |
受信任的 本地沙箱 |
远程沙箱 |
|---|---|---|---|---|
| 访问 SWF 的沙箱 | ||||
| 供文件系 统使用的 本地沙箱 |
加载: 允许 跨域脚本处理: 允许 |
加载: 不允许 | 加载: 允许 跨域脚本处理: 允许 |
加载: 不允许 |
| 供网络 使用的 本地沙箱 |
加载: 不允许 | 加载: 允许 跨域脚本处理: 允许 |
加载: 允许 跨域脚本处理: 允许 |
加载: 不允许 |
| 受信任的 本地沙箱 |
加载: 允许 跨域脚本处理: 需要权限 |
加载: 允许 跨域脚本处理: 需要权限 |
加载: 允许 跨域脚本处理: 允许 |
加载: 不允许 |
| 远程沙箱 | 加载: 不允许 | 加载: 允许 跨域脚本处理: 需要权限 |
加载: 允许 跨域脚本处理: 允许 |
加载: 允许 跨域脚本处理: 如果域不匹配, 则需要权限 |
加载限制
表 1 中的红色单元格表示某些 SWF 无法加载其它 SWF 的情形 使用 loadMovie、loadMovieNum 等 :
- 远程 SWF 通过 HTTP 和其它非本地协议提供 不能加载本地 SWF。
- 供网络使用的本地 SWF 不能加载供文件系统使用的本地 SWF, 反之亦然。
- 供文件系统使用的本地 SWF 不能加载远程 SWF。 这实际上是已讨论规则的结果: 加载远程 SWF 需要使用远程 URL 调用 loadMovie, 这是一种网络发送操作, 因此会对供文件系统使用的本地 SWF 禁止。
必要时可以转化后两个规则, 因为很容易将 SWF 从供文件系统使用的本地 SWF 更改为供网络使用的本地 SWF, 反之亦然。
但是, 第一个规则, 即远程 SWF 不能加载本地 SWF, 是绝对的。与 Flash Player 中其它大多数安全规则不同, 它无法转化。该规则避免了所谓的区域扩大, 其中权限较少的区域 远程 SWF 中的内容可激活具有更多潜在权限区域 本地 SWF 的内容。如果发现自己处于一个维护混合的远程-本地应用程序的非寻常位置, 而该应用程序将在用户访问网页时启动本地安装的内容, 那么最好的选择是更改您的起点, 让用户通过查看随后激活联机内容的本地 SWF 或本地放映文件、本地可执行文件等 开始。
Flash Player 在调用 getURL 时具有类似规则, 即加载浏览器页面而不是 SWF:
- 远程 SWF 不能使用本地 URL 调用 getURL
- 供文件系统使用的本地 SWF 可以使用本地 URL 调用 getURL, 但是这样做之后, 将失去任何查询参数或锚记 URL 的一部分, 后跟“?”或“#”符号 。
跨域脚本处理权限
表 1 中黄色的单元格表示某个 SWF 将可以对其它 SWF 进行脚本处理的情形, 条件是被访问 SWF 明确授予该操作的权限。这些情形包括:
- 一个不受信任的本地 SWF 处理本地受信任 SWF 的脚本；本地受信任的 SWF 必须授予权限
- 供网络使用的本地 SWF 处理远程 SWF 的脚本；远程 SWF 必须授予权限
- 远程 SWF 处理来自不同域的另一个远程 SWF 的脚本；被访问 SWF 必须授予权限 远程到远程规则在 Flash Player 7 中未作更改
为遵循 Flash Player 的全局权限原则, 其中前两种情形需要被访问 SWF 授予权限, 才能访问所有沙箱中的 SWF。这意味着要调用 System.security.allowDomain "*" , 或者对于 LocalConnection 对象, 则意味着要提供一个 LocalConnection.allowDomain 处理函数, 当为该函数提供指定“localhost.”的域参数时, 它将返回一个 True 值。
永久共享对象
Flash Player 6 和更高版本通过 SharedObject 类支持永久共享对象。永久共享对象将数据存储在用户的计算机上。它们通常是通过 SharedObject.getLocal 获得的本地共享对象, 也可以创建永久远程共享对象；这需要 Flash Media Server 以前为 Flash Communication Server , 在该产品中记录了远程共享对象。
每个远程沙箱对永久共享对象都有一个关联的存储。例如, 当来自 domain1.com 的任何 SWF 读取或写入永久共享对象时, Flash Player 将在 domain1.com 对象存储中读取或写入该对象。与此类似, 对于来自 domain2.com 的 SWF, Flash Player 将使用 domain2.com 存储。为避免名称冲突, 可通过路径进一步识别永久共享对象, 默认路径是创建 SWF 的 URL 全路径, 但是使用 SharedObject.getLocal 的 localPath 参数可缩短该路径, 该路径创建后将允许来自相同域的其它 SWF 访问共享对象。
在 Flash Player 7 和更早版本中, 所有本地 SWF 都共享一个永久共享对象存储。从 Flash Player 8 开始, 提供了两个本地共享对象存储。重复以前的模式, 通过将共享对象存储分别分配给这两种本地沙箱中的每一个, Flash Player 可以确保供文件系统使用的本地 SWF 不会与供网络使用的本地 SWF 通信。
Flash Player 将受信任的本地 SWF 分配到与供文件系统使用的本地 SWF 相同的共享对象存储。这可帮助简化供文件系统使用的状态 默认 和受信任状态之间的转换 这样最终用户可以按预期方式对停止运行的现有本地内容选择采取的修复措施 。当 SWF 执行这样的转换时, 它们将保留已创建的任何共享对象。
本地安全性方案
以下方案旨在帮助说明 Flash Player 8 中的新本地安全规则的效果。
用户方案: Flash 作者和同事
设计 Flash Player 8 本地安全规则的目的是为了帮助保护最终用户。对于最终用户而言, 本地 SWF 通常是最终内容, 即从 Internet 下载的内容或作为应用程序的一部分安装的内容。但对于 Flash 作者而言, 本地 SWF 通常只是开发中内容的临时副本, 即通常是要绑定以在 HTTP 服务器上进行最终部署的内容。有时, 您可能会遇到阻止内容正常运行的安全限制, 这只是因为您正预览的 SWF 仍然是本地文件。
请考虑使用以下三种方法来测试开发中的 Flash 内容, 这三种方法按复杂性依次递增的顺序排列:
- 在 Flash 创作应用程序中测试影片。测试影片播放器根本不强制实施新的本地安全规则, 因此在测试影片模式中应该不会出现任何问题。
- 使用独立播放器或浏览器播放器查看本地 SWF。这可能会产生因新规则而导致的问题, 例如, 当 SWF 使用 HTTP URL 调用 getURL 时。
- 将 SWF 放在 HTTP 测试服务器上, 并使用浏览器进行查看。这种形式的测试同样不会引发本地安全问题, 这是因为通过 HTTP 查看的 SWF 不是本地 SWF；它们运行于 Flash Player 远程安全规则之下, 而这些规则在 Flash Player 8 中并未更改。
如果 Flash Player 能够区分开发中的 Flash 内容与从 Internet 下载的不受信任的 SWF, 则上述方法将非常理想和有用, 它可以在使用浏览器进行预览的测试中避免出现不需要的安全限制。遗憾的是, 没有可靠的自动方式来使 Flash Player 实现此测试。
相反, 您可能会发现, 将 Flash Player 配置为信任本地文件系统中某一区域内的所有 SWF 将非常有用。例如, 如果将所有 Flash 工作都存储在 C:\FlashSites 下, 则可以访问 设置管理器并将目录 C:\FlashSites 添加到受信任路径的列表中。此后, 只要查看 C:\FlashSites 或其任意子目录中的任何 SWF, Flash Player 就会将这些 SWF 放在受信任的本地沙箱中, 以免出现任何与安全相关的故障。如果执行了此操作, 那么一定不要将不受信任源中的 SWF 放到信任区域中！将您自己的本地 SWF 与其它作者的不受信任的 SWF 分离, 这样便可加强对您的保护, 如同对所有 Flash Player 最终用户的保护一样。
假设您已访问设置管理器并已配置了受信任的目录。那么, 您现在即可以开展自己的工作, 而不受安全问题的困扰。但是, 您可能需要将开发中的 SWF 与众多同事 (HTML 作者、Flex 开发人员、位图艺术家等) 共享。或者, 您可能希望向经理或客户演示您的 SWF。而他们中的一些人可能并未在其计算机中设置受信任的目录, 因此如果这些人以本地文件的方式打开您的 SWF, 并且 SWF 尝试与 Internet (例如, 通过调用 getURL) 或 HTML 页通信, 则在对您的内容进行本地预览时, 本地安全规则可能会导致这些内容无法正常运行。此外, 由于这些“延伸”用户可能没有在其计算机中安装 FlashAuthor.cfg, 因此如果您的 SWF 是版本 8 或更高版本, 那么这些人甚至无法看到提示故障原因的警告对话框。
遗憾的是, 尚没有一种方法可以处理这些延伸用户问题。基本问题是, 如果 Flash Player 在您同事的计算机上运行, 则它无法区分 (临时) 本地 SWF 和从 Internet 下载的可能不受信任的 SWF。
解决此延伸用户问题最可靠的方法是将 SWF 张贴到 HTTP 测试服务器上, 然后发送链接, 而不是将 SWF 作为文件来发送。但有时这样做可能不方便于或无法使用这种方法, 例如, 如果您没有专用 HTTP 服务器, 或者您需要将 SWF 与您网络以外的人共享, 而且您不想将 SWF 张贴到公共服务器上。因此, 您可能需要考虑使用其它方法:
- 创建 SWF 放映文件
- 将 SWF 发布为供网络使用而非供本地文件系统使用
- 为 SWF 项目创建可设置 FlashPlayerTrust 文件的安装程序
- 向同事发送设置管理器配置说明
- 请求同事将 SWF 张贴到他们自己的服务器上
适用于您的最佳解决方案取决于您的具体情况。
用户方案: Flash Player 最终用户
在大多数情况下, Flash Player 最终用户应该看不到新的本地安全规则。但如上所述, 某些用户可能具有为了与 Internet 通信而编写的本地 Flash 应用程序。当这些用户升级到 Flash Player 8 时, 他们可能会看到一个对话框, 告知他们存在潜在不安全的操作。
在此情况下, 用户的选择非常简单。他们可以决定忽略该问题, 可以与应用程序供应商联系以咨询解决方法, 也可以选择自行尝试并解决该问题。
决定解决该问题的用户可以单击警告对话框中的“设置”按钮。此时用户将进入设置管理器, 他们可以在此阅读有关本地安全的信息, 选择“编辑位置” › “添加位置”, 然后选择要信任的本地路径。指出需要信任的路径并非总是很繁琐；有时只信任警告对话框中出现的单个路径便足已, 但有时一个应用程序中可能涉及多个 SWF。在这种情况下, 可能需要信任包含这些 SWF 的整个目录。每次猜测受信任的路径后, 用户必须返回到初始应用程序并重新启动该应用程序, 例如, 通过刷新浏览器来执行此操作。
进入设置管理器后, 用户还可以选择“始终允许”信任版本 7 及更早版本的所有 SWF。与确定信任路径相比, 这种解决方法更为简单, 但它在提供这种便利的同时, 降低了用户的安全性。
应用程序方案: 修复混合帮助系统
假设您正在维护使用本地 SWF 的应用程序, 并且有用户反映在查看应用程序的某些部分时看到提示可能存在不安全操作的 Flash Player 安全对话框。假定您的应用程序是一个混合帮助系统, 该系统是本地 SWF 应用程序的一种常见形式: 使用 getURL 或 fscommand 通信的 HTML 和 SWF 文件的集合。
第一步应该是确定问题的严重性。是一个重要应用程序的关键组件出现了重大问题？还是业余项目中的一个小功能被破坏了？是否要向所有用户重新分发修复后的文件？答案通常是肯定的, 但在进行修复之前务必确认修复需求。
一种方法是只告知用户访问设置管理器并信任帮助系统所在的路径。但某些用户可能会因步骤过多而无法完成, 并且如果用户不理解安全决策的含义, 则有可能给他们带来不便。
另一种方法是将 SWF 重新发布为供网络使用, 或使用 Local Content Updater 对这些 SWF 进行后处理。如果您的内容所产生的唯一安全冲突来自对 getURL 的调用, 则这种方法应足以解决问题。但是, 如果您的 SWF 和 HTML 文件使用 fscommand、getURL("javascript:...") 或其它混合脚本处理操作, 则供网络使用的本地沙箱不足以将应用程序恢复到以前的状态；必须将 SWF 放在受信任的本地沙箱中。
如果用户的技术知识丰富, 则可以为他们提供 FlashPlayerTrust 文件以及放置该文件的说明。或者, 也可以创建可在适当位置自动创建 FlashPlayerTrust 文件的小脚本或程序。如果您知道 SWF 的安装位置, 则只需信任您希望它们所在的目录。但是, 如果用户选择了非默认安装位置, 则可能需要提示用户提供您的内容的安装位置, 或在他们的文件系统中搜索您的 SWF。
应用程序方案: 偶尔连接的联系人管理器
这是最后一个方案, 我们假设您正在构建本地 SWF 应用程序, 该应用程序可定期与 HTTP 服务器同步数据, 而在其它时间则用作该数据的本地存储库。讨论的数据可能是一个地址簿, 因此将此应用程序视为“偶尔连接的联系人管理器”。
假定您已经确定需要网络发送权限, 而不是本地读取权限, 例如, 您不需要读取本地 XML 文件以进行配置。因此, 在发布 SWF 时, 需在 Flash 发布选项中的“本地回放安全性”下选择“只访问网络”。现在, 您的 SWF 可以随意使用 getURL、XML.load 和其它 HTTP 操作。
现在, 您可以将应用程序连接到 HTTP 数据源, 以进行同步。假定您使用 XML.sendAndLoad() 来交换简单的 XML 数据。由于 XML.sendAndLoad 是一个网络读取操作, 因此您需要在正与之同步的 HTTP 服务器上有一个策略文件。假设您希望该策略文件只控制相关数据, 而不是整个 HTTP 服务器, 因此您将该文件放在 XML 数据源旁, 并在客户端 SWF 中调用 System.security.loadPolicyFile, 以指定该策略文件的位置。策略文件如下所示:
<cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
策略文件必须信任所有位置 ("*") , 供网络使用的本地 SWF 才能依照全局权限原则从您的服务器加载数据。
这即将实现！
本地安全性示意图
下面的示意图对上面各节中描述的本地安全权限进行了总结。
来源和沙箱
在将 SWF 加载到 Flash Player 中时, 会将所有 SWF 放到一个沙箱中。图 5 显示了如何基于 SWF 的来源将其分配给沙箱。来自网络 (例如 a.com 和 b.com）的 SWF 始终位于和其来源域相对应的沙箱中。
本地来源 (本地文件系统或 UNC 网络路径）的 SWF 位于三个沙箱之一内。默认情况下, 本地 SWF 位于供文件系统使用的本地沙箱中。已声明希望访问网络的本地文件位于供网络使用的本地沙箱中。注册为受信任 (通过设置管理器或配置文件）的本地文件位于受信任的本地沙箱中。 (在 Flash Player 7 及更早版本中, 所有本地文件都位于受信任的本地沙箱中。）
在同一沙箱中的任意两个 SWF 彼此之间可以自由交互。后面的关系图说明了 SWF 如何与其它沙箱中的 SWF 以及文件系统和服务器交互。
默认权限
在图 5 中, 箭头表示 SWF 来源。在下面的一系列关系图中, 箭头则表示访问。虚线箭头表示数据加载, 而轮廓箭头表示跨域脚本处理。图 6 演示了用于默认沙箱中 SWF 的权限。
默认情况下, 本地 SWF 位于供文件系统使用的本地沙箱中。从此沙箱中, SWF 可以 (例如, 使用 XML.load() ）从本地文件系统或 UNC 网络路径上的文件中读取数据, 但不能以任何方式与 Internet 通信。
除了远程 SWF 无法再加载本地内容之外, 远程 SWF 的权限与 Flash Player 7 中的权限没有差异。远程 SWF 始终位于和其来源域相对应的沙箱中。通过 a.com 沙箱, SWF 可以从位于 a.com 的服务器中读取数据 (例如, 使用 XML.load() ）, 并且可以将数据发送到 Internet 上的任意位置 (例如, 使用 XML.send() ）。
远程 SWF 的权限
图 7 演示了远程 SWF 的权限, 这些权限在默认情况下不可用, 但可以授予这些权限。
如果 b.com 包含允许从 a.com 或所有域进行访问的策略文件, 则来自 a.com 的 SWF 可以从位于 b.com 的服务器读取 (例如, 使用 XML.load）数据。如果 b.com SWF 调用 System.security.allowDomain("a.com") , 则来自 a.com 的 SWF 可以对来自 b.com 的 SWF 进行跨域脚本处理 (例如, 在 b.com SWF 中调用 ActionScript 方法）。Flash Player 7 中提供了这些权限, Flash Player 8 中并未对它们进行更改。
默认情况下, 远程 SWF 不能对本地 SWF 进行跨域脚本处理。但是, 允许供网络使用的本地 SWF 和受信任的本地 SWF 授予由远程 SWF 使用 System.security.allowDomain() 跨域处理脚本的权限。不允许供文件系统使用的本地 SWF 授予此类权限, 因为这可能导致供文件系统使用的本地 SWF 和远程 SWF 合作读取本地文件系统中的数据, 并将该数据发送给 Web 服务器。
受信任的本地 SWF 的权限
图 8 演示了给予受信任的本地 SWF 不受限制的权限。受信任的本地 SWF 可以从本地文件读取数据, 与任意服务器交互, 还可以对其它任何 SWF 进行脚本处理。
供文件系统使用的本地 SWF 的权限
图 9 演示了供文件系统使用的本地 SWF 的特权, 这些权限默认情况下不可用, 但可以通过授权来授予。受信任的本地 SWF 可以使用 System.security.allowDomain("*") 授予权限, 以便由供文件系统使用的本地 SWF 进行脚本处理。
请注意, 只能通过向所有域授予权限来向供文件系统使用的本地 SWF 授予权限。所有域要求反映了这样一个事实, 即允许供文件系统使用的本地 SWF 访问等于允许任何人访问, 因为 Flash Player 无法确定本地 SWF 的来源。
不能由远程 SWF 或供网络使用的本地 SWF 向供文件系统使用的本地 SWF 授予权限, 因为这可能导致供文件系统使用的本地 SWF 与远程或供网络使用的本地 SWF 合作读取本地文件系统中的数据, 并将该数据发送至 Web 服务器。
缺少权限时, 只允许供文件系统使用的本地 SWF 从本地文件系统中加载数据 (例如, 使用 XML.load() ）。
供网络使用的本地 SWF 的权限
图 10 演示了将自身声明为供网络使用而非供文件系统使用的本地 SWF 可用的默认权限。缺少权限时, 只允许供网络使用的本地 SWF 与其它供网络使用的本地 SWF 通信, 并将数据发送至服务器 (例如, 使用 XML.send() ）。
供网络使用的本地 SWF 的权限
图 11 演示了供网络使用的本地 SWF 的权限, 这些权限默认情况下不可用, 但可以通过授权来授予。
如果 a.com 包含允许从所有域进行访问的策略文件, 则允许从 a.com 的服务器中读取供网络使用的本地 SWF。
如果 a.com SWF 调用 System.security.allowDomain("*") , 则允许供网络使用的本地 SWF 对来自 a.com 的 SWF 进行跨域脚本处理 (例如, 在 a.com SWF 中调用 ActionScript 方法）。类似地, 如果受信任的本地 SWF 调用 allowDomain("*") , 则允许供网络使用的本地 SWF 对受信任的本地 SWF 进行跨域脚本处理。
注意, 只能通过向所有域授予权限来向供网络使用的本地 SWF 授予权限。所有域要求反映了这样一个事实, 即允许供网络使用的本地 SWF 访问等于允许任何人访问, 因为 Flash Player 无法确定本地 SWF 的来源。
无法建立允许供网络使用的本地 SWF 从本地文件读取数据的任何权限。
数据流摘要
图 12 总结了当具有一组最大权限时可能存在的数据流。
使用权限, 供网络使用的本地 SWF 可以与远程 SWF 和服务器完全互操作。还可以使受信任的本地 SWF 与网络资源自由通信, 反之亦然。
但请注意, 即使具备这样的一组最大权限, 数据也必须通过受信任的本地 SWF, 才能从本地文件系统流向 Internet。
Flash Player 嵌入与本地安全性
可以生成嵌入 Flash Player 的本地应用程序, 将其作为一个组件包括在自定义 GUI 中。这只适用于作为可执行程序生成的本机本地应用程序。
Macromedia 目前不支持 Flash Player 的这种用法, 但也不禁止。在应用程序中使用 Flash Player 有一定的风险, 因为您不能随应用程序一起重新分配 Flash Player, 这将使您不得不依赖于用户计算机中安装的 Flash Player 版本。由于用户随时都可能会升级 Flash Player, 因此您应用程序的行为容易出现无法预期的更改。
尽管存在这些问题, 但 Macromedia 还是会努力避免嵌入 Flash Player 的应用程序出现不适当的故障。
Flash Player 8 和更高版本在嵌入时具有以下本地安全行为:
- 当 Flash Player ActiveX 控件检测到它位于非浏览器容器内时, 它将禁用新的本地安全规则, 并将所有本地 SWF 置于受信任的本地沙箱中。即使 ActiveX 控件在位于非浏览器容器内的 Internet Explorer ActiveX 控件实例中被实例化, 也是如此。请注意, 这只与最终 容器应用程序有关。因此, 如果您具有嵌入 Flash Player ActiveX 控件的 ActiveX 控件, 而该 ActiveX 控件又被嵌入到 Internet Explorer 中, 则 Flash Player 将检测到它在浏览器中运行, 并且启用本地安全。
- Flash Player 插件播放器不检测其容器是否为浏览器；默认情况下, 它们始终启用新的本地安全规则。但是, 如果最终用户 (使用设置管理器) 或安装程序 (使用 FlashPlayerTrust 配置文件) 指定信任嵌入 Flash Player 插件的可执行应用程序的路径, 则当该插件嵌入该可执行文件中时, 它将禁用新的本地安全规则。
- ActiveX 和插件播放器具有导出的 API, 这些 API 允许宿主应用程序选择是否希望实施新的本地安全规则。必须在 Flash Player 生存周期的早期、在加载任何内容之前调用这些 API。具体如下所示:
ActiveX (IDispatch APIs):HRESULT IShockWaveFlash::EnforceLocalSecurity() HRESULT IShockWaveFlash::DisableLocalSecurity()
插件 (DLL 导出): NPError Flash_EnforceLocalSecurity() NPError Flash_DisableLocalSecurity()
如果您正在开发嵌入 Flash Player 的本地应用程序, 则应该明确确定是要启用还是要禁用本地安全规则, 并调用相应的 API。通常, 如果需要使用 Flash Player 播放来自您无法控制的来源 (例如 Internet) 的内容, 则应选择启用本地安全规则。相反, 如果只播放您可以控制并且随应用程序一起分发的特定 SWF, 那么禁用本地安全会很方便, 这样可获得最大的灵活性。
第三方存储
使用 Flash Player 8 及更高版本的用户所具有的选择与许多浏览器为第三方 Cookie 提供的选择类似: 用户可以禁用第三方域中的 SWF 对客户端永久共享对象的读取和写入。默认情况下, 将启用第三方存储；用户可以通过访问Flash Player 设置管理器并取消选中“允许第三方 Flash 内容在您的计算机上存储数据”来禁用第三方存储。第三方 SWF 是任意 SWF, 其来源域和用户访问的主域 即浏览器的地址栏中显示的域 不匹配。
第三方存储选项既影响本地共享对象, 又影响它不为人所熟知的同类 即永久性远程共享对象 , 这些对象只可与 Flash Media Server 以前称为 Flash Communication Server 结合使用。
如果禁用第三方存储, 并且 SWF 尝试使用 SharedObject.getLocal 或 SharedObject.getRemote 获取共享对象, 那么 Flash Player 将确定调用 SWF 是否为第三方。Flash Player 将 SWF 的来源域和浏览器地址栏中显示的域进行比较, 如果两个域不完全匹配, 则将该 SWF 归类为第三方。如果 SWF 为第三方, 则对 getLocal 或 getRemote 的调用返回 null。
第三方存储限制不影响本地 SWF 从用户的文件系统中加载的 SWF ；它只影响远程 SWF。由于对第三方 SWF 的分类需要与浏览器 URL 进行比较, 因此仅当 Flash Player 在 Web 浏览器中播放时, 它才关注第三方限制；独立播放器、放映文件和 Flash 创作播放器则不关注此限制。
如果您受到影响
如果您的 SWF 确实为第三方, 也就是说, 它被并入其他人的站点, 那么您必须接受这样的事实, 即某些用户不允许您的 SWF 读取或写入共享对象。有关对此现象根源的讨论, 请参见下一节。
如果您的 SWF 被视为第三方, 但只在您能控制的站点内使用, 那么您可能需要重新组织站点, 以便始终可以从用户访问的主域提供需要读取或写入永久共享对象的所有 SWF。
为什么限制第三方存储？
网上冲浪是隐私和便利之间的一种折衷。用户通常无法避免某些个人情况的泄露 例如他们的 IP 地址及选择的操作系统和浏览器 , 通常情况下, 用户都希望对大部分个人信息进行保密, 除非他们有意向已知的受信任方提供信息。近年来争论的有关用户个人配置文件方面的一个问题是浏览历史记录, 因此跟踪 Web 内容存储的信息可能会泄露历史记录。如果许多不同站点以类似方式对特定用户的访问进行记录, 那么同一站点或其它站点日后便可以读取所有信息以了解该用户的浏览习惯, 有些用户 以及用户隐私的公共倡导者 会感觉他们的隐私受到侵犯。
此类跟踪记录通常存储在以下两个位置: Web 服务器和用户自己的计算机上。类似 Web 浏览器和 Flash Player 这样的客户端技术不会影响 Web 服务器上发生的行为, 因此, 此方法始终可供希望了解用户浏览历史记录的各方使用。但在服务器中存储浏览记录存在以下主要缺点: 需要存储空间以及服务器到服务器的通信, 这两项的费用比较昂贵。此外, 通常很难通过多次访问来标识用户, 因为 IP 地址等标识特征可能会随时间而改变, 或者由多个用户共享。因此, 如果可能, 历史记录跟踪器更愿意将浏览历史记录存储在用户自己的计算机中, 以记录使用给定计算机访问的站点。
用于存储此类信息的两种技术是浏览器 Cookie 和 Flash 中的永久共享对象。浏览器和 Flash Player 实现来源相同的安全策略, 从而可以阻止站点读取其它站点建立的 Cookie 或共享对象。由于此限制, 每个参与站点不足以在自己的数据存储区中存储浏览记录；其它任何站点则无法读取此信息以生成集合历史记录。而较常采用的一种技术是指定某个域来记录所有历史记录信息, 然后让每个参与站点引用该域中的历史记录写入文档, 并传递用于检索该文档的 URL 中的站点标识信息。在以后的访问中, 常用域中的历史记录读取文档可以访问由 Cookie 写入文档写入的所有记录, 这样便会泄露部分用户浏览历史记录。
Web 浏览器和 Flash Player 现在允许用户控制使用此技术跟踪其历史记录的方式。浏览器和 Flash Player 为用户提供禁止读取和写入“第三方”永久数据的选项。从此意义上讲, 第三方被定义为与用户访问的主域 浏览器地址栏中显示的域 不匹配的任意域。例如, 如果用户在禁用第三方存储后访问 http://site1.com/index.html, 而 index.html 包括 http://common.com/writeHistory.html?domain=site1.com, 并且 writeHistory.html 尝试读取或写入永久数据, 则浏览器或 Flash Player 将不允许执行该操作, 因为 common.com 是第三方域；用户在其浏览器中看到的将是 site1.com, 而不是 common.com。
allowScriptAccess 默认值
Flash Player 自版本 6 以来, 一直支持一个称为 allowScriptAccess 的 HTML 参数。此参数用于控制是否允许 SWF 中的 ActionScript 在包含它的 HTML 页中调用 JavaScript。 反之则不进行控制, 即 JavaScript 调用受 System.security.allowDomain 控制的 ActionScript。
allowScriptAccess 可能存在如下值:
- always: 始终允许 ActionScript 调用 JavaScript
- sameDomain: 仅当 SWF 和 HTML 页来自同一域时, 才允许 ActionScript 调用 JavaScript
- never: 从不允许 ActionScript 调用 JavaScript
在 Flash Player 6 和 7 中, allowScriptAccess 的默认值 如果未由 HTML 页指定 为“always”。需要单独说明的是, 在 Flash HTML 发布模板中, allowScriptAccess 的默认值始终为“sameDomain”。如果不修改 Flash HTML 发布进程输出, 那么您将会看到“sameDomain”行为, 这是因为 HTML 页会为 Flash Player 指定“sameDomain”。
在 Flash Player 8 中, 当 Flash Player 中的主 SWF 为 7 版或更早版本时, 未指定的 allowScriptAccess 的默认值将始终为“always”, 而当主 SWF 为 8 版或更高版本时, 该默认值会变为“sameDomain”。
allowScriptAccess 参数允许 HTML 页包括 Flash 内容, 但禁止它在 HTML 页中执行脚本。当 HTML 页源自它可能并不信任的 Flash 内容时, 这一点很有用。例如, 如果您负责维护一个论坛, 其中的用户可能会包括他们自己制作的 SWF 签名, 并且生成的 HTML 将直接源自这些 SWF, 那么您可能不希望这些 SWF 能够在您的 HTML 页中执行脚本。
下面是有关如何指定 allowScriptAccess 的示例:
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="375" height="300"> <param name="movie" value="hello.swf"> <param name="allowScriptAccess" value="sameDomain"> <embed pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" src="hello.swf" width="375" height="300" allowScriptAccess="sameDomain"> </object>
allowDomain 通配符支持
注意: 本节介绍的更改同时适用于 System.security.allowDomain() 和 System.security.allowInsecureDomain()。为进行详细说明, 只介绍 System.security.allowDomain；对 System.security.allowInsecureDomain() 的更改与之相同。Macromedia 不建议您调用 System.security.allowInsecureDomain(), 因为这会降低 SSL (HTTPS) 所提供的安全性。
从 Flash Player 8 开始, System.security.allowDomain() 接受单个星号“*”作为通配符。调用 System.security.allowDomain("*") 的结果是允许通过所有 域而非特定域中的其它 SWF 进行脚本访问。
如果您所在的环境中没有需要保护的敏感数据, 并且您需要公开与其它域共享数据, 则使用此通配符权限会很方便。但在调用 System.security.allowDomain("*") 之前, 请确保调用 SWF 不包含需要保密或半保密的任何信息或 ActionScript 代码。调用 System.security.allowDomain("*") 后, 来自 Internet 中任意位置的任意 SWF 都可以加载您的 SWF 并对其进行脚本处理, 即便 SWF 由恶意作者编写时也是如此。
请注意, 在以下情况中, 您可能必须调用 System.security.allowDomain(), 即在运行之前, 您不知道提供协作 SWF 的域, 这可能是因为协作 SWF 由负载平衡簇提供, 或者是因为将在多个不同域中使用您的 SWF。在此情况下, 请勿盲目调用 System.security.allowDomain("*")！如上所述, 这将打开您的 SWF, 从而完全允许 Internet 上的其它任何 SWF 对其进行脚本处理。请等至协作 SWF 加载完毕, 然后使用 ActionScript property MovieClip._url 确定它的域。在将 _url 属性值传递给 System.security.allowDomain() 之后, 引用的影片剪辑中的 SWF 应该能够对调用 System.security.allowDomain() 的 SWF 进行脚本处理。
Flash Player 8 允许任意版本的 SWF 向 System.security.allowDomain() 传递“*”。但如果您要在低于 8 版的 SWF 中调用 System.security.allowDomain("*"), 那么在执行操作前, 一定要测试播放器的版本 (System.capabilities.version) 看是否至少为 8, 这是因为较早版本的 Flash Player 不会将“*”识别为 System.security.allowDomain 的参数。
更精确的权限
注意: 本节介绍的更改同时适用于 System.security.allowDomain() 和 System.security.allowInsecureDomain()。为进行详细说明, 只介绍 System.security.allowDomain；对 System.security.allowInsecureDomain() 的更改与之相同。Macromedia 不建议您调用 System.security.allowInsecureDomain(), 因为这会降低 SSL (HTTPS) 所提供的安全性。
调用 System.security.allowDomain() 时, 建立的权限中将涉及以下两方: 授予 方, 它是调用 System.security.allowDomain() 的 SWF；使用 方, 它是在 System.security.allowDomain() 的参数中指定的域。建立此权限后, 使用域中的任一 SWF 都可以对授予 SWF 进行脚本处理。
在 Flash Player 6 和 7 中, 使用域中的任一 SWF 不仅能对授予 SWF 本身进行脚本处理, 还可对授予 SWF 的域 中的任何 SWF 进行脚本处理。授予方被视为授予域, 而非授予 SWF。例如, 如果来自 http://site1.com/app1.swf 的 SWF 调用 System.security.allowDomain("site2.com"), 则来自 http://site2.com/another.swf 的 SWF 可以对来自 http://site1.com/app1.swf 的授予 SWF 进行脚本处理, 也可以为从 site1.com 加载的其它任何 SWF (例如 http://site1.com/different.swf) 进行脚本处理。
这一方案有时会产生令人惊讶的结果。site1.com 的维护人员可能会管理众多不同且彼此无关的 Flash 应用程序, 并可能需要允许外部域访问其中某些应用程序, 但并不希望外部域访问 site1.com 中的所有 应用程序。app1.swf 的作者可能并未意识到通过调用 System.security.allowDomain("site2.com"), 他们不仅允许访问 app1.swf 而且还允许访问 different.swf。
当版本 8 或更高版本的 SWF 调用 System.security.allowDomain() 时, 调用 SWF 是唯一的授予方。如果同一域中两个不同的 SWF 都希望允许外部域访问, 则希望允许进行该访问的每个 SWF 都必须调用 System.security.allowDomain()。
此行为仅适用于版本 8 或更高版本的 SWF。为了保持向后兼容性, 调用 System.security.allowDomain() 的 6 或 7 版 SWF 即便是在 Flash Player 8 中播放, 仍将对自身域中所有的 6 和 7 版 SWF 授予访问权。但是, 调用 System.security.allowDomain() 的 6 或 7 版 SWF 不会对自身域中 8 版或更高版本的 SWF 授予访问权。
已对 System.exactSettings 进行了相同行为的更改, 以便确定 SWF 是使用其 Flash 6 样式超域 (例如, mysite.com 是 www.mysite.com 的超域) 还是使用其 Flash 7 样式精确域 (例如, www.mysite.com) 作为摄像机/麦克风权限以及永久共享对象的基础。在 Flash Player 7 中, 如果域中的某个 SWF 更改了 System.exactSettings 的值, 则该更改将应用于同一域中的所有 SWF。在版本 8 或更高版本的 SWF 中, 设置 System.exactSettings 只影响调用 SWF。
安全的永久共享对象
在 Flash Player 8 和更高版本中, 源自 HTTPS URL 的 SWF 在读取或写入永久共享对象时可以指定它希望使用单独存储区中的共享对象, 而该存储区只能由通过 HTTPS 提供的 SWF 访问。此类共享对象不易遭受下面所述的假想攻击。除 HTTPS 要求外, 用于访问安全存储区中共享对象的规则与用于非安全共享对象的规则相同: 默认情况下, 只有与原创建者位于同一 URL 的 SWF 才可以访问共享对象, 但如果创建者指定了比其完整 URL 短的 localPath 选项, 那么 URL 以相同前缀开始的其它 SWF 也可以通过指定相同的 localPath 来访问共享对象。
检索安全共享对象
若要检索安全共享对象, 请为名为 secure 的新的可选参数向 SharedObject.getLocal() 或 SharedObject.getRemote() 传递一个 true 值:
static function getLocal(name:String, localPath:String, secure:Boolean) : SharedObject;static function getRemote(name:String, remotePath:String, persistence:Object, secure:Boolean) : SharedObject;
(请注意, 远程共享对象需要 Flash Media Server, 并且仅随该产品提供。)
例如, 要检索安全的本地共享对象:
var mySO = SharedObject.getLocal("userInfo", null, true);
(localPath 取空值与完全忽略 localPath 具有相同的效果, 因此, 如果您需要一个包含默认 localPath 的安全共享对象, 则请为 localPath 传递 null。)
请注意, secure 标记默认为 false, 这表明此新功能不会影响在 Flash Player 8 之前的版本中创建的 SWF, 只有特别请求安全共享对象的 SWF 将使用这一新的、单独的安全存储区。由早期 SWF 创建的所有共享对象 (无论是否为 HTTPS) 均位于最初的非安全存储区中。
如果来自非 HTTPS URL 的 SWF 为 secure 参数传递了 true, 则 getLocal() 或 getRemote() 调用将返回 null。
请注意, 安全和非安全共享对象来自完全独立的空间, 因此可能获得两个具有相同名称、localPath 和域但彼此独立的永久共享对象 (一个是安全的, 一个是非安全的)。例如, 如果某 HTTPS SWF 创建了一个名为“userInfo”并且 localPath 为“/”的安全共享对象, 随后另一个 HTTP SWF 检索到一个名为“userInfo”并且 localPath 为“/”的非安全共享对象, 那么第二个共享对象实际上独立与第一个对象, 因为这两个对象来自不同的存储区。
为什么使用安全共享对象？
安全的永久共享对象针对未经授权方为访问敏感数据而进行的假想类尝试提供保护。
HTTPS 协议可提供几种重要的保护。其中最著名的保护是加密, 它可以阻止网络中的第三方看到网络对话的内容。而另一个重要的优点是完整性, 它可以确保当一方向另一方发送数据时, 数据能够到达目的地而不被修改, 或者如果到达时被修改, 则可检测到修改并视数据无效而将其拒绝。这有助于阻止中间人攻击, 该攻击可利用 Internet 的分布式特征: 网络对话中的一方 (例如 ISP 的员工、网络运营商、代理服务器、防火墙等) 不仅可以侦听对话, 还可以修改发送到任一方向的数据, 这可能会导致他们插入自己的文档, 以在发送方毫不知情的情况下代表发送方执行操作。例如, 如果用户访问 example.com 并查看要求提供登录信息的 SWF, 则中间人攻击者可以替换他或她的几乎相同的 SWF, 这不仅会将用户的登录信息发送给预计的收件人, 而且还会将其发送给攻击者。但如果通过 HTTPS 保证该连接的安全, 则当客户端收到中间方的已修改的 SWF 时, 客户端将拒绝该 SWF, 攻击将失败。
作为补充, 另一种类似的攻击基于对提供 SWF 的站点进行模拟, 该攻击可利用 DNS 或用于标识服务器的其它系统中的漏洞。HTTPS 的另一个名为身份验证 的属性通过使用 SSL 证书验证服务器的身份来击败此类攻击。我们的目的在于讨论中间人攻击是否能够同时涵盖中间人攻击和模拟攻击。
如果您通过 HTTPS 提供 SWF 并从该 SWF 写入永久共享对象, 那么您可能有足够的理由希望该共享对象中的数据仅可用于您自己的 SWF。实质上, 是供用户使用。例如, 您可能要在一个永久共享对象中记录敏感信息, 例如帐户信息或财务数据。您要确认您的某一用户是否受到了中间人的攻击, 那么理想情况是, 攻击者将无法访问该共享对象中的数据。
在 Flash Player 7 中, 如果您的 HTTPS SWF 编写了一个共享对象, 并且随后一个用户经中间人攻击者的诱骗访问了您站点中可从中访问该共享对象的一个 URL (实际上, 该 URL 可能是提供 SWF 的 URL) , 但由于使用 HTTP 而非 HTTPS 存在一些关键差异, 因此可能会导致攻击者发送自己的 SWF, 并且 Flash Player 将认为该攻击者的 SWF 来自于您的站点。然后, 攻击者的 SWF 便可以读取共享对象并将其内容报告给攻击者。
当然, 这些攻击很难组织起来。如果您部署了已在永久共享对象中写入敏感数据的 HTTPS SWF, 那么并不是所有人都会使用此类型的攻击来尝试访问您的数据。但是, 为了在日后获得最佳保护, 如果您在永久共享对象中存储了敏感数据, 则应考虑使用安全共享对象。
下一步该做什么
作为世界上分布最广泛的软件之一, Flash Player 凭借其丰富多样的媒体功能、稳定性以及可信赖性在众多的计算机和设备中赢得了自己的一席之地。除了新的表现功能和改进的性能外, Flash Player 8 还为其数亿用户增强了网上冲浪的安全性。这一点必将引起关注。Flash Player 将继续维护它在安全专业领域可信赖软件的名誉, 从而使用户可以控制自己的个人信息。
本文中讨论的增强功能并非毫无成本。遍布世界各地的数百万计的 SWF 中的一小部分将在无意间受到这些新用户保护措施的影响, 而且是通过作者最初无法预料的方式。Macromedia 不会放松此类开发, 我们已花费了相当多的时间来在这些安全更改的成本与利益之间进行权衡。Flash 作为“部署一次, 永无后患”的技术, 已经树立了坚不可摧的名誉。新的 Flash Player 版本甚至可以像第一次发布一样播放最旧的 Flash 内容。无论如何, 我们始终对 Flash Player 用户负责。在使 Flash Player 赢得所有人信任的过程中, 我们将保证为丰富媒体提供一个长期、稳定的未来。