征服 Ajax 应用程序的安全威胁
Ajax 构建于动态 HTML（DHTML）技术之上，其中包括如下这些最常见的技术：
JavaScript：JavaScript 是一种脚本语言，在客户端 Web 应用程序中经常使用。 文档对象模型（Document Object Model，DOM）：DOM 是一种用于表示 HTML 或 XML 文档的标准对象模型。如今，大多数浏览器都支持 DOM 并允许 JavaScript 代码动态地读取和修改 HTML 内容。 层叠样式表（Cascading Style Sheets，CSS）：CSS 是一种用于说明 HTML 文档表示的样式表语言。JavaScript 能够在运行的时候对样式表进行修改，这样便可以动态地更新 Web 页面的表示。在 Ajax 中，客户端 JavaScript 通过动态地修改 DOM 树和样式表来更新 Web 页面。此外，异步通信（可以通过下面介绍的技术实现）允许动态地更新数据，而无需重新加载整个 Web 页面：
XMLHttpRequest ：XMLHttpRequest 是一个 API，它允许客户端的 JavaScript 与远程服务器建立 HTTP 连接和交换数据，比如说纯文本、XML 和 JSON（JavaScript Serialized Object Notation）。 JSON：JSON 由 RFC 4627 提出，是一种轻量的、基于文本的、独立于语言的数据交换格式。它以 ECMAScript 语言的一个子集为基础（这使之成为 JavaScript 语言的一个部分），并且定义了一小套格式规则用以创建结构数据的可移植表示。注意，Ajax 应用程序中还有一些其他常用的格式可以替代 JSON，比如说 XML 和无格式的纯文本。此处我们选择讨论 JSON，其原因在于它具有一些隐藏的安全问题，稍后我们将在文章中对其进行研究。
建议对 Ajax 还不熟悉的读者先阅读 参考资料 中的文章。
?
标记导入 HTML 文档的 JavaScript 文件被认为是该 HTML 文档的同源的一部分。该策略在所有主要浏览器实现中都有执行。
?
在 XMLHttpRequest 的上下文中，同源策略的目的是控制应用程序与远程服务器的交互。然而，同源策略对 Web 2.0 应用程序的影响力比较有限，这有如下几个原因：
?
可以通过许多方法绕过同源策略：稍后我将在文章中演示其中的一些方法。 Web 2.0 应用程序的一个重要特性就是用户对内容的贡献：也就是说，通常内容并不是由受信任的服务提供的，而更多的是由异步用户通过 blog、wiki 等媒介提供的。因此，即便是单个服务器中的内容实际上也能够来自多个来源。 浏览器强制同源策略将服务器的域名作为串字面值进行检查：例如，http://www.abc.com/ 和 http://12.34.56.78/ 会被作为不同的域而区别对待，即使 www.abc.com 的 IP 地址实际上就是 12.34.56.78。此外，URL 中的任何路径表达式都将被忽略。例如，http://www.abc.com/~alice 会被识别为 http://www.abc.com/~malroy 的同源，从而忽略了这样一个事实，即这两个目录有可能属于不同的用户。 大多数 Web 浏览器允许 Web 应用程序将域的定义放宽为应用程序自身的超域：比如说，如果应用程序是从 www.abc.com 处下载的，那么应用程序可以把document.domain 属性重写为 abc.com 或者就是 com（在 Firefox 中）。大多数最新的浏览器只允许访问已经把它们的 document.domain 属性重写为相同值的窗口或框架中的窗口对象。然而，一些版本比较老的浏览器允许与 document.domain 属性中指定的域建立 XMLHttpRequest 连接。 即使某个 Web 服务器位于受信任的域中，该服务器可能并不是内容的始发源，尤其是在 Web 2.0 的上下文中：比如说，企业门户服务器、基于 Web 的邮件服务器或者 wiki 可以是受信任的，但是他们所托管的内容可能包含来自具有潜在的恶意的第三方的输入，这个第三方可以是跨站脚本（cross-site scripting，XSS）攻击（该攻击我们将在稍后介绍）的目标。因此，服务器所在的域并不能代表其内容的可信任度。?
? 当 JavaScript 代码动态地插入 ? ? 假设 trusted.com 提供了一个服务，该服务具有一个搜索特性能把搜索结果和输入的关键字一起提交回来。如果搜索应用程序没有过滤 URL 中的一些特殊字符（如小于号 (<) 和大于号 (>)），则 ? 随着 Web 2.0 的普及 stored XSS 攻击越来越严重。Web 2.0 成功的关键是大众之间的共享、交互和协作，因此用户有更多的机会可以通过一些服务（比如说社会网络服务（social network services，SNS）、wiki 或 blog）看到其他用户（具有潜在恶意性）的输入。 ? 不管怎样，输入值验证和数据消毒（sanitation）是防止 XSS 攻击的关键因素。通常，Web 服务器从用户输入中移除脚本，但是攻击者经常会利用服务器的弱点绕过这些过滤器，从而造成一些重大的攻击，比如说 Yamanner 或 MySpaceIn 蠕虫。 ? ? 在本例中，攻击者需要等待一段时间，直到用户单击提交按钮之后才能接收到他的数据。Ajax 使攻击者的工作更加简单，这是因为它允许攻击者向远程服务发送任意信息，而不用等待利用用户的动作，比如说点击一个按钮或单击一个链接。这种类型的通信量通常会被视为可疑行为，但是由于 Ajax 具有异步性，所以这种通信量常常不会被检测到。 ? 使用类似的方法，攻击者还能够窃取敏感 Web 应用程序中的文档 cookies（比如说在线金融应用程序）。文档 cookies 可以允许攻击者劫持会话或使用所窃取的凭证进行登录。 ? 注意，Microsoft? Internet Explorer? 6 或更高版本对 ? ? var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test( text.replace(/"(\\.|[^"\\])*"/g, ' '))) && eval('(' + text + ')');? 另一种更具安全性的方法是使用 JSON 解析器对 JSON 进行解析。由于 JSON 的语法相当的简单，您可以轻易地实现这种解析器，而不会带来显著的性能差异。 ? 在集成不可信内容时使用 <iframe> 您可以利用同源策略使攻击者无法轻易地访问整个 DOM 树。当您把不同域中的数据加载到一个 结束语 在这篇文章中，我们概述了在 Web 2.0 应用程序中避免同源策略的各种不同的方法。我们还演示了这些方法如何在 Web 应用程序中公开一些新的攻击点。我们讨论了一些常见的攻击类型和这些攻击所带来的后果。最后，我们在简短的最佳实践部分中对文章进行了总结，使用这些最佳实践可以避免一些最常见的攻击。 ? ? 来源：https://www.ibm.com/developerworks/cn/xml/x-ajaxsecurity.html ? ? ? ? ? ? ? ? ? ?<script> 标记时，浏览器会访问 src 属性中的 URL。这样会导致将查询字符串中的信息发送给服务器。在 清单 1 中，所传递的是 username 和 reservation 作为名称值对传递。此外，查询字符串还包含向服务器请求的输出格式和回调函数的名称（即 showItinerary）。<script> 标记加载后，会执行回调函数，并通过回调函数的参数把从服务返回的信息传递给该回调函数。<script> 标记也将被插入到用户 Web 页面中，这样将会把文档的 cookie 发送给远程服务器 evil.com。HttpOnly cookies 提供了支持，这样可以防止客户端脚本访问文档 cookies。然而，由于大多数 Web 应用程序都不能依赖浏览器来实现，所以这种方法也无济于事。<iframe> 中时，应该给予该数据一个属于自己的 JavaScript 执行上下文和 DOM 树。这样可以防止攻击者从主页面中窃取信息。尽可能多地 <iframe> 限制不可信的外部内容是一个良好的实践。