通过沙箱实现安全保护

应用程序沙箱的主要功能是支持 AIR API 与受信任目录中的文件之间的交互。隔离非应用程序沙箱中的代码是通过在加载初始页面后禁用 JavaScript 分析器来维护的，因此 eval() 这样的代码会引发异常。允许设置 innerHTML ，但是其中包含的任何脚本都将被忽略。这样无需将 AIR API 直接向外部加载的数据公开即可提供广泛的功能。

开发人员可以使用 app:/ URL 架构引用应用程序沙箱中受信任目录。甚至可以将应用程序目录中的一些文件放置到非应用程序沙箱中，前提是：使用 frame 或 iframe 的 AIR sandboxRoot 和 documentRoot 属性将这些文件加载到 frame 或 iframe 中。AIR 安装程序中包括的所有文件都会自动安装到 app:/ 下，从而成为应用程序沙箱的一部分。应用程序运行时，这些文件会被授予一整套 AIR 应用程序权限，包括与本地文件系统交互。 app:/ 外部的内容并非应用程序沙箱的组成部分，因此应按浏览器中的内容对待。

AIR API 为安全地将不断发展的浏览器安全模型与桌面风格的安全模型桥接在一起提供了一种安全方式。较之典型的基于浏览器的应用程序，AIR 沙箱桥模型功能更广泛、风险更小。

非应用程序沙箱的主要功能是限制对本地文件和 AIR API 的访问，只有得到开发人员的许可才能对其进行访问。 从网络或 Internet 位置加载的内容将自动分配给此沙箱。非应用程序沙箱可以使用 eval() 函数，通过 innerHTML 赋值执行代码等。非应用程序沙箱中的代码受同源策略的约束，默认情况下，无法通过 XMLHTTPRequest 执行跨域数据加载。但是，非应用程序沙箱中的代码无法直接执行 AIR API。

鼓励开发人员编写在应用程序沙箱中运行的代码，即使对此沙箱的一些限制使其行为方式与浏览器模型相比略有不同。

最简单的情况是，使用网络内容的基于 HTML 的 AIR 应用程序包含根用户界面 (UI) 文件、应用程序下载的数据和文件，以及一些应用程序文件（在应用程序沙箱中）。但是，如果外部内容和一些用户界面文件在非应用程序沙箱中运行，应用程序文件在应用程序沙箱中运行，那么非应用程序沙箱内容与应用程序沙箱内容之间将如何进行交互？

AIR 解决方案为 沙箱桥 API，可实现不同沙箱之间的间接通信。开发人员可以编写调用 AIR API 的函数，然后在沙箱桥上公开这些“中间”函数。这些桥函数实质上“位于桥上”，等待非应用程序沙箱中的代码调用它们。

此体系结构实现了两个目标。首先，非应用程序沙箱内容不能直接访问 AIR API，应用程序内容得到保护，防止未知和可能存在恶意的外部数据访问。其次，只有那些开发人员明确选定通过桥机制公开的 API 才能公开。

虽然沙箱桥并不能保证安全性，但是开发人员可以通过控制向不受信任的内容公开 AIR API 的方式来降低风险。这非常类似于客户端-服务器模型，服务器永远不应信任客户端，而客户端永远不应信任从第三方加载的数据。同样，开发人员不应使用或信任服务器上加载的代码，这些代码可能会危及服务器的安全，进而获得对操作系统的访问权。因此，对于浏览器和 AIR 沙箱桥中的客户端-服务器模型，应始终保护原始系统 API（如 writeFile() 和 readFile() ）以防受到攻击。

Adobe AIR 安全性在设计上考虑到了 Web 应用程序开发社区。Adobe 支持有助于降低安全风险的标准和方法。包括 OpenAjax Alliance 在内的多个组织正进一步帮助宣扬这些最佳做法：

• 隔离 frame 或 iframe 中不受信任的内容，利用同源策略使攻击者难以访问整个 DOM 树。

• 对于加载到不同域的帧中的数据，应给定一个唯一的 JavaScript 执行上下文和 DOM 树。

• 不要动态生成和执行代码。

• 只可插入受信任的来源的 HTML 内容。

• 安全地使用 JSON。

  AIR 为开发人员提供了一些遵循这些最佳做法的机制，从而增强了基于 HTML 的应用程序的安全性。有关详细信息，请参阅 OpenAjax Alliance 上的 Ajax and Mashup Security 。

  开发人员必须明确指出桥接沙箱。