日前网络中流行围绕AJAX和安全风险的讨伐声浪让人不绝于耳。这种火热的新技术已经被铺天盖地地应，用在各种web应用(构建如Gmail、Google Maps这些基于web的应用)，但在其炙手可热的光环背后隐藏着一个黑暗的鬼怪——AJAX正在为心怀恶意的hacker打开着后门。

但这并不完全正确。恰好，目前几乎所有的web应用开发老手和安全专家都正在力图冲过冷嘲热讽式的取笑，触及到事情的真相：多数web站点都是不安全，但AJAX并不是罪魁祸首。尽管AJAX不能使web站点变得丝毫安全，但理解它能做些什么是非常重要的。

AJAX(Asynchronous JavaScript + XML)是web浏览器技术的集合体，它允许web页面内容飞速地更新而无需刷新页面。在使用AJAX的web页面背后，数据(通常格式化为XML，但也可以是HTML、JavaScript等格式)在web服务器与客户端浏览器之间来回传输。比如在Gmail应用场景中，新的邮件信息被自动接收和显示。在Google Maps应用场景中，用户可以通过鼠标拖拽的方式在地图中的街区之间穿梭漫游。这种执行异步数据传输的机制是一个嵌入在所有现代web浏览器内部的、被称为XMLHTTPRequest(XHR)的软件库。XHR是web站点获得“AJAX”商标的关键。另一方面，它也是一些实现了“奇思妙想”的JavaScript。

如果你正在思考这究竟和安全有什么关系，那么你是正确的。AJAX技术使站点平滑地与用户交互，并给用户带来更多的回应。而在web服务器上并没有任何改变，而安全焦点却应该着重在web服务器端。如果这是事实的话，那么我们每个人还考虑什么?在计算机安全社区中，AJAX意味着大量攻击平面(attack surface)、骤增的复杂性、伪造请求、拒绝服务、跨站脚本(XSS)、依赖于客户端安全等等。而事实上，这些问题在AJAX出现之前就已经存在。并且推荐给开发者的安全最佳实践也从没有因为AJAX的出现而改变过。如果你像我一样想知道到底哪些才是重要的，那么请让我们进行一次深入的讨论。

名词解释

Cross-site scripting (XSS):跨站脚本是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻击者利用XSS漏洞越过访问控制——例如同源策略(same origin policy)。近来，这种类型的漏洞被用来编写危害性更大的phishing攻击和利用浏览器漏洞。详细解释请看这里。

Same Origin Policy:计算机术语。这里译为“同源策略”。它是对于客户端脚本(尤其是JavaScript)的重要安全 度量标准。它首先出自Netscape Navigator2.0。之后历经Navigator2.01和Navigator2.02的修正完善。其目的在于防止某个文档或者脚本从多个不同 “origin”(源)装载。 这里的单词“origin”指使用域名、协议、端口。详细解释请看这里。

Cross-site request forgery(CSRF):跨站请求伪造，也被称成为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS)，但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范，所以被认为比XSS更具危险性。详细解释请看这里。

AJAX导致大量的“攻击平面”?——不!

“攻击平面”一词被应用到通过对系统中开放攻击点的分析来度量安全的概念中。对于软件，这些点便是被第三方(用户)操作数据输入、输出的区域。显而易见，具有相对越少的安全平面使应用越安全。同样明显的是，对于web应用或者任何应用，编写的功能点与攻击平面同样多。这并不和用户接口是否采用AJAX、Flash、ASCII艺术字或者其它任何方式有关。AJAX是一种浏览器技术，且不在服务端执行。当AJAX驱使开发者公开地暴露更多的功能时，便可能引入新的“服务器端”漏洞——你并不能责备AJAX。新的代码总意味着增加漏洞的风险。

更进一步讲，从本人的经验看，使用AJAX技术的web应用在功能上并不具有比传统的标准web应用更多的复杂性。Google Maps就是一个比看似简单的craigslist的更简练的应用。Gmail也比Outlook Web Access更加轻巧。而且，使用AJAX进行Web应用设计(或者重新设计)将给在使用新式平台上(.NET，J2EE等)进行开发带来更多的机会。这些平台与生俱来就更加安全、不会出现例如SQL注入、证书会话推算(Credential Session Prediction)、目录遍历等在上一代平台中常见的漏洞。

AJAX使“攻击平面”更加难以发现?——是，但又不是

没有测试结果的安全程序是不完整的。度量web站点安全的最常见方式便是通过模拟攻击——成千上万的攻击(也就是漏洞评估)。漏洞评估能被手工执行，也可以使用自动化扫描工具，或者两者兼而有之。在漏洞评估过程的第一步就是定位web应用的输入点或者“攻击平面”。因此，一个完整的漏洞评估需要发现所有可能的漏洞。

自动化抓取整个web站点、映射链接是漏洞评估的标准行为。此方法对于某些站点工作很好，对另一些站点则无能为力，而对其余站点的效果在前两者之间。对使用大量JavaScript、Flash、ActiveX、Applet和AJAX的新式站点来讲，进行漏洞评估的挑战是网站中的链接是即时生成或者在复杂的客户端代码中动态生成的。分析出这些链接非常困难，有时几乎不可能。因此自动化扫描成为了检验AJAX站点安全性的一种不大可靠的方法。

另一方面依靠人工可以相对轻松地详细审视代码并推断代码之间的关系。有时，JavaScript源代码中记录了web站点所有的输出区域，甚至XML web服务的细节，当然这不但对心怀善意者有用，而且对心存恶意者也同样有用处。

在一个平常的web站点中，没有这样的资源，而漏洞评估程序必须依赖于链接抓取的方式。因此这里做出的结论便是：AJAX并没有削弱web站点的安全性，但它使评估安全工作面临更多的挑战。

AJAX导致“拒绝服务”?——这并非事实

基于AJAX的web站点被要求设计成为使用大量零碎的HTTP请求，而不是少量的、大规模HTTP请求的应用。例如，Google Suggest在每个用户敲击键盘时，可以发出微小的HTTP请求来执行自动单词完成工作。这里假定1000用户同时使用此系统，采用这种AJAX快速触发HTTP请求的模式将会明显地提高系统处理请求的压力。这便是潜在的拒绝服务场景。假定这是可能的，但这是谁的过错呢?

以本人的观点，这个问题不是因AJAX、甚至不良的软件设计策略而引起的、而是缺乏恰当的实现和质量测试而造成的。针对此问题的解决方案便是优化配置或者增加更多的web服务。现实中，如果某人想发动Dos攻击，他将使用巨大的HTTP流量作为洪流冲击网络，而不管web站点是否采用AJAX。