AJAX真的不安全？！

前言

        日前网络中流行围绕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。

AJAX依赖客户端安全？——不！

         让我们回到web应用安全上来。Web应用必须从不信任客户端（web浏览器）。这是无论web页面接口使用JavaScript、Flash、 ActiveX、Applet、AJAX或者其它协议、语言都适用的“福音”。每个开发者应该谨慎对待HTTP代理，因为它能改变HTTP请求中的任何东 西、甚至是那些被XHR生成的数据。最谨慎的做法是确保所有安全检查都在server上进行，无一例外。
        这意味着我们不应该使用客户端安全检查吗？不，正相反。我推荐在form中和其它业务处理流中使用客户端安全检查，因为它通过更多的反馈完善了用户体验。把用户在电话号码field中输入的字符传送到服务器进行检查的做法是没有必要的。而且通过将部分处理时间推给客户端可以减轻服务器的负载。

AJAX导致糟糕的安全决策？——有几分可能。

        Web2.0 站点经常囊括了来自一个或者多个第三方站点的数据，这称为“mash-up”。AJAX开发者首选的做法是使用直接从第三方站点“拉”数据给用户，这样可 以减少没必要的带宽浪费。但是这对XHR技术来讲是不可能的。XHR具有内建在浏览器中的安全保护机制，它防止位于A站点的用户浏览器向B站点发起连接。 这有助于防止用户受到那些在页面中使用JavaScript代码强迫用户下载银行账户信息的恶意站点的威胁。

        而Web开 发者并不愿抑制革新，他们完成了一套能够使用XHR访问第三方站点的应用：Web开发者在web服务器上建立一个本地HTTP代理。为了使客户端能够从第 三方站点“拉”数据，他们通过本地代理将XHR直接传送给目的服务器。下面便是web浏览器生成的请求示例：


http://websiteA/proxy?url=http://websitesB/

        A站点接收进入的请求，而后“proxy”web应用通过“URL”参数发送请求给B站点。通过使用代理，开发者可以使用XHR作跨域请求。因为A站点不能直接连接到B站点，所以XHR不能发送用户授权cookie到B站点， 因此这里并不存在跨域请求伪造（CSRF）的威胁。这里安全问题时A站点上存在一个没有进行限制的HTTP代理。

        攻击者喜欢寻找开放的代理，因为他们能够从那里发起攻击，而不必暴露自己的行踪。代理的使用应被仔细地控制，对连接代理的站点和此站点的行为进行限制。我认为问题出在开发者忽视了安全控制，而不是AJAX。

AJAX使跨站脚本攻击（XSS）更甚？——我希望不是。

        AJAX使得XSS攻击更甚？记得在2006年BlackHat发表的一篇《Hacking Intranet Websites from the Outside》中演示了JavaScript恶意代码如何获取内网NAT后的IP地址、扫描端口、使web服务器记录系统失明、盗取浏览器历史记录、利用处于内网的web接口。华盛顿邮报称此“使人不安”。所有的演示代码没有使用AJAX编写，都是古老的JavaScript。

XHR能够发起在同一域下的任何HTTP请求，并浏览回应数据。简单的JavaScript能够完成同样的请求，而无需“域”的限制，但它不能浏览回应数据。这意味着如果某个用户位于A网站，XHR不能强迫用户连接到B网站、并读取B网站的数据。但是简单的JavaScript代码能够做到。从这个角度来看，XHR是如等的安全！

对于JavaScript的深入研究已经导致了新生的恶意代码能够发现哪些服务器具有潜在的XSS漏洞安全问题。更为直接的例子就是，Samy蠕虫曾经击倒了MySpace，利用XHR的JS-Yamaner也在Yahoo上肆虐繁殖过。但是这些攻击都采用简单的JavaScript。AJAX与这种场景毫无干系。我们所能做的是寻找和修复在web应用中的XSS漏洞。WhiteHat的安全白皮书《Cross-Site Scripting Worms and Viruses》中提供了更丰富的资源。

AJAX改变了安全最佳实践？——不。

        如果某个web应用存在漏洞，那么无论采用何种技术进行开发，它都是不安全的。如果某个web应用具备良好的设计，“不安全的AJAX”怎么也削弱不了它的安全性。
下面是使web应用安全的5点提示：

1）设计安全。进行从安全出发、时刻关注安全的设计：在软件开发生命周期中每个阶段中将安全性作为一个组件对待。

2）可靠的输入验证。从不信任客户端。

3）使用可靠的软件库。从加密到会话管理，最好尽量使用经过全面的测试的组件。不要重新发明轮子和重复别人的错误。

4）安全配置。web站点的每个组件都应该使用职责相互分离的配置，最小化权限，屏蔽掉不使用的特性，禁用错误信息。

5）寻找和修复漏洞。持续化的漏洞评估是预防攻击者访问公司和客户数据的最佳方式。因为你不能控制那些无法测试到的。

        遵守上面的5点提示是使Web应用走向安全的第一步。第二步则是数据验证。没有哪家公司指望能编写没有任何缺陷的代码，或者具有连续不断定位web应用中所有安全漏洞能力的有效工具。这就是WhiteHat建立WhiteHat Sentinel这个提供持续的漏洞评估和web应用管理服务的原因。

记住基本原则，使用深层防御，你的在线业务将更安全。

针对XSS蠕虫和病毒的最佳防范方法

    近十年来，反病毒社区已经建立了依靠快速反应时间来限制蠕虫和病毒所造成的危害的机制。随着新一代恶意软件滋生速度的提高，几百万、甚至上亿美元在病毒突 发事态趋于稳定之前白白损失掉了。这种情况要求我们采取措施在病毒刚发作时对病毒的爆发进行辨别，防止病毒在第一发生地点扩大化。

        为了缩小新种类病毒和蠕虫的危害，下面列举出了一些防范步骤供web用户、web开发者参考：

web用户

1.在电子邮件或者即时通讯软件中点击链接时需要格外小心：留心可疑的过长链接，尤其是它们看上去包含了HTML代码。如果对其产生怀疑，可以在浏览器地址栏中手工输入域名，而后通过该页面中的链接浏览你所要的信息。

2.对于XSS漏洞，没有哪种web浏览器具有明显的安全优势。也就是Firefox也同样不安全。为了获得更多的安全性，可以安装一些浏览器插件：比如Firefox的NoScript或者Netcraft工具条。

3.然而，世界上没有“100%的有效”。尽量避免访问有问题的站点：比如提供hack信息和工具、破解软件、成人照片的网站。这些类型的网站会利用浏览器漏洞并危害操作系统。

web应用开发者

1.对于开发者，首先应该把精力放到对所有用户提交内容进行可靠的输入验证上。这些提交内容包括URL、查询关键字、http头、post数据等。只接受在你所规定长度范围内、采用适当格式、你所希望的字符。阻塞、过滤或者忽略其它的任何东西。

2.保护所有敏感的功能，以防被bots自动化或者被第三方网站所执行。实现session标记（session tokens）、CAPTCHA系统或者HTTP引用头检查。

3. 如果你的web应用必须支持用户提供的HTML，那么应用的安全性将受到灾难性的下滑。但是你还是可以做一些事来保护web站点：确认你接收的HTML内 容被妥善地格式化，仅包含最小化的、安全的tag（绝对没有JavaScript），去掉任何对远程内容的引用（尤其是样式表和JavaScript）。 为了更多的安全，请使用httpOnly的cookie。