打造安全 Ajax mashup 的未来

当前的 Web 浏览器设计不能轻松而安全地从多个源获取内容并将其显示到页面上。了解开发人员如何充分利用可用的工具来完成该任务，以及使用这些工具给所得应用程序带来的安全和可伸缩性方面的压力。另外，学习提出的几种用于补救此情形的浏览器改进，以及如何参与相关讨论，使 Web 开发超越这一障碍，使互操作性达到的一个新水平。

与 Ajax 混合

mashup 是一个 Web 应用程序，它集成了来自多个源的内容并将其交付到一个页面中进行显示。服务器向每个内容源发出请求，解析收到的信息，并将结果综合到一个页面中发给浏览器，如 图 1 所示。

图 1. 混合来自多个源的内容

Asynchronous JavaScript + XML（Ajax）应用程序 使 Web 页面能从服务器获取内容并使用 JavaScript™ 代码异步地在适当位置进行自我更新，如 图 2 所示。这样，用户就可以与富用户界面 (UI) 进行交互而无需重新加载整个页面。服务器向浏览器发送初始页面，后者回调服务器以获取更新后的内容。异步的 JavaScript 代码调用频繁使用 XML 来编码数据；但是，其他的数据格式则更通用，如 JavaScript Object Notation (JSON)、HTML 和分隔文本。

图 2. 使用 Ajax 的交互式数据显示

Ajax mashup 是一种混合的 Web 应用程序。它使用 Ajax 技术来显示富 UI，此类富 UI 使用从多个源异步检索到的内容在适当位置进行自我更新。服务器向浏览器发送初始页面，后者发出调用以检索更新后的内容。这些调用可从浏览器直接发往第三方源或者发回初始服务器，初始服务器用作第三方内容的代理。

回页首

格格不入

当设计包含当前浏览器环境的元素时，没有人注意到 Ajax mashup。浏览器、超文本传输协议（HTTP）或 HTML 或专门设计用于容纳浏览器的（以一种安全而健壮的方式）异步检索多个源中内容的功能的 XHTML 都没有内置任何组件。World Wide Web Consortium (W3C) HTTP 规范中的一些可能用于 mashup 的一些特性（如 Document Object Model (DOM) Level 3 Load 和 Save Specification）并未由大多数浏览器完全实现，或是根本没有实现。

Dynamic HTML (DHTML) 开始时不与动态检索到的内容结合使用。动态 Web 页面的显示和数据元素都与操作它们的脚本一起交付。这些脚本将显示、隐藏、移动、创建和销毁文档对象以便实现动态效果，但是一旦需要从服务器获取更多数据，原页面就被新页面取代。数据流与页面重新加载同步。

因此，希望构建混合 Web 应用程序（现在称为 mashup）的开发人员必须利用可用的技术设法对其进行扩展以满足他们的需求。有两种方法可使浏览器在无需重新加载页面的情况下检索内容：嵌入外部传输机制和使用浏览器本地对象执行传输任务。

外部帮助

早期的解决方案是 Microsoft 的 Remote Scripting，它使用一个 Java™ applet 与服务器端组件交换 XML 格式的消息。此方法很快就因为供应商的争论以及 Java Virtual Machine (JVM) 和安全模型的差异而变得不实用。

Microsoft 稍后构建了 XMLHttpRequest (XHR) 对象，其设计者的预想是只能通过 Microsoft® Outlook® Web Access (OWA) 来使用该对象。该对象最初只能由 Windows® Internet Explorer® 用户使用，直到多年后 Mozilla 和 Safari 采用它时，才得到广泛使用。它最初是一个外部的 Microsoft ActiveX® 对象，而当前的实现则是浏览器内的本地对象。虽然其名称为 XHR，但是 XHR 对象却可以传输任意格式的数据而非仅限于有效的 XML 格式数据。

很多开发人员使用 Macromedia Flash 的 XML 通信特性来构建可嵌入的组件与服务器进行通信。XMLSocket 和 flex.net.socket 对象提供了类似 XHR 的功能，但附带了额外的通信控制和 XML 解析功能。

内部工作

由于外部传输机制相关的问题和依赖性，互联网开发团体协作发现并开发了几个浏览器本地的远程调用方法。

• 使用一个隐藏的 iframe 元素来加载外部内容：然后通过 DOM 访问 iframe，提取加载文档中的内容。您可指定 URL querystring 中的任何参数或动态创建一个表单，此表单以 iframe 为目标提交到服务。此方法与很大范围内的当前的和旧式浏览器兼容。
• 使用 img 元素发送内容请求：服务器使用 URL 的 querystring 中的参数执行其任务，然后在 cookie 中返回编码后的内容。此方法仅限于可轻松通信数量的数据使用，因为 querystring 和 cookie 都有大小限制。
• 在当前页面的 DOM 中动态创建脚本元素：加载后，立即执行服务器所提供的代码。服务器使用 URL querystring 中的参数。

请参阅 参考资料 中关于这些工具和技术的详细信息的链接。

回页首

突破界限

大多数可用于异步检索内容的技术都继承了 JavaScript 安全模型的安全性，它使脚本只与源于该脚本所属页面所在的同一服务器的元素进行交互。这就是所有浏览器都实现了的同源策略（Same Origin Policy）。

要让 Web 页面从第三方检索内容，必须避开同源策略。常用的不受同源策略限制的例外是 <script> 标记技术，由此向页面的 DOM 追加 <script> 元素，致使其加载并运行元素的 src 属性所指定的 URL 处发现的代码。

使用 <script> 标记运行来自多个站点的脚本以所有相关站点间的高水平信任为前提，因为所有此类脚本都在相同的执行和安全上下文中运行，因此可能获得其他站点的信息和 cookie 的访问权。

回页首

安全或可伸缩性：不可兼得

当前广泛用于启用 Ajax mashup 的工作区都会产生一些代价。当扩展浏览器的设计限制时，就会影响应用程序总体操作的其他方面。这种做法通常会导致应用程序的安全性或可伸缩性降低。

安全，但是否可伸缩？

当受到浏览器的同源策略限制时，承载应用程序的服务器必须承担获取第三方内容并将其发送到客户机的任务。服务器除提供常规的服务器功能外，还担当第三方服务的客户机的角色。

使用服务器作为每个客户机事务的代理意味着大量用户可能导致过度的服务器负载。使用此技术的应用程序需要设计成服务器端可伸缩，使用多个同等的服务器处理请求负载。

可伸缩，但是否安全？

使用 <script> 标记避开同源策略使客户机能检索来自第三方的内容。 此功能消除了服务器的可伸缩性瓶颈，因为每个额外的客户机都承担了自身的内容收集任务。

<script> 标记的可伸缩性优点的获得以避开同源策略安全性模型为代价，可能导致易于收到攻击：

• 跨站点 cookie 访问成为可能：一个站点的脚本可访问另一个站点的 cookie。
• 在运行检索到的代码之前不能检查其安全问题：代码加载后立即运行。

回页首

可能的解决方案

很明显，浏览器当前提供的用于 mashup 的工具不能构建同时具有可伸缩性和安全性的应用程序。开发人员必须找到从当前和长远角度来看都有效的解决方案。

此时此地

一种最近开发的内容检索技术通过其 src URL 的片段标识符（URL 中 # 符号后的部分）使用了页面脚本和隐藏的 iframe 之间的通信。父页面中的脚本和嵌入的 iframe 可设置彼此的片段标识符，尽管它们来自不同的起源。脚本之间保持一种一致的通信协议，由 JavaScript 计时器驱动，该计时器定期地激活例程以检查片段标识符中的更改。

由于脚本必须了解彼此的地址并且它们自身之间必须协作以取得对协议的一致遵守，因此要确保信任。由于任何服务器交互都在每个组件本地并且与脚本间通信分离，因此不会暴露 cookie。

虽然仍不完美（例如，它依赖于设计行为以外的异常，并且查询更改不如用事件激活来响应更改），但是这个解决方案比任何其他方案都更接近于提供浏览器本地的、安全的、页面中的跨域通信。

请注意：James Burke 是 AOL Developer Network 的一名开发人员，他开创了片段标识符技术并将其构建到最新版本的 Dojo Toolkit JavaScript 库中。

长期

浏览器制造商和开发团体当前正在讨论几种可能的修改浏览器环境元素的方法，使其以 Ajax mashup 为构建目标。Web Hypertext Application Technology Working Group (WHATWG) 在其用于 Cross Document Messaging 机制的 Web Applications 1.0 Working Draft 的 7.3 节中提出了一个建议。Opera 浏览器已经实现了此特性。它指定了不同域中的 DOM 对象之间协作通信的方法，该方法允许消息的接收方根据消息的起源来选择所要响应的消息。

Ian Hickson 以前任职于 Opera，现在任职于 Google。他提出了对现有的 XMLHttpRequest 对象的跨站点扩展。他的提议包括对发出请求的方式（包括报头控制的限制和访问控制机制）的几个修改。

Douglas Crockford 是任职于 Yahoo! 的一名 JavaScript 传道者和架构师，他是全球最有造诣的 JavaScript 语言专家之一。您可在他的个人 Web 站点上及通过 Yahoo! Developer Network 找到很多他的解释高级 JavaScript 技术的展示和文章。Crockford 提出的另一项计划是 JSON，它是一种 Ajax 应用程序中广泛使用的数据交换格式，其主要原因是易于被 JavaScript 解析并且不像 XML 那样冗余。Crockford 编写了两个提议来将 mashup 敏感的元素构建到浏览器中。

绝妙提议

几个绝妙提议可帮助您应对此困境：

• JSONRequest 提议：浏览器实现一个新对象，其运作方式类似于现有的 XMLHttp 对象，作出了以下几点修改：
  • JSONRequest 将免除同源策略。
  • 将使用 HTTP 报头的最小设置，减小请求的总体大小。
  • 不传输 cookie，确保避免跨站点 cookie 问题。
  • JSONRequest 将只接受有效的 JSON 文本，确保不将原始的可执行代码发送执行。
  • 通信失败后，在重试阻止某些攻击类之前引入随机延迟。
  • 每个请求都将返回一个序列标识符，使异步响应能 更容易地与其原始请求相关联。
  • 对双向连接的特定支持将使服务器能通过开放的通信通道异步地启动通信。
• <module> 标记提议：新的 HTML 标记将页面分隔成彼此不受影响但可安全地通信的模块集合：
  • The <module> 标记将能够访问第三方资源，免除同源策略。
  • 页面和模块间的合作通信只能通过特定的接口来进行。模块间不能相互通信 —— 只能与页面通信。页面可使模块间的通信更加方便。
  • 通信仅限于有效的 JSON 文本， 相比之下，与 JavaScript 对象通信可能因为附带的代码导致 安全泄漏。
  • 提出了一些限制用于确保模块和页面不会干扰彼此的显示，避免导致安全问题。
• 内容限制题头： Gervase Markham 提出了内容限制题头规范， 该规范使作者能表达全部意图 —— 确定内容与其他站点内容的交互方式。一致的实现将提交包含策略字符串的内容限制题头。
• W3C Access Control List (ACL) System：W3C ACL System 可用作 基于 ACL 的系统的模型，用来管理对 Ajax mashup 中服务 HTTP 的资源的访问。
• Cross-browser.xml：Flash 对象在服务器上查找 cross-browser.xml 文件，然后才尝试访问其特定的 URL。 此文件指定了哪个站点可承载访问该服务器上所提供服务的应用程序。很多 Web 服务提供方已经实现了此文件。

请参阅 参考资料 中关于这些提议的详细信息的链接。