`
cleverpig
  • 浏览: 148548 次
  • 性别: Icon_minigender_1
社区版块
存档分类
最新评论

AJAX真的不安全?!

阅读更多
AJAX真的不安全?!

作者:cleverpig

image


原文永久链接:http://www.matrix.org.cn/resource/article/2007-02-07/a5f2d5c6-b677-11db-82df-078095a5dcde.html

前言

        日前网络中流行围绕AJAX和安全风险的讨伐声浪让人不绝于耳。这种火热的新技术已经被铺天盖地地应        用在各种web应用(构建如GmailGoogle 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蠕虫和病毒的最佳防范方法

image
我们如何吃下这袋中甜点?


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

        为了缩小新种类病毒和蠕虫的危害,下面列举出了一些防范步骤供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

参考资源

什么是跨站脚本(XSS)?
什么是跨站请求伪造(CSRF)?
同源策略的定义
Myth-Busting AJAX (In)security
BlackHat于2006年发表的《Hacking Intranet Websites from the Outside》
WhiteHat的安全白皮书《Cross-Site Scripting Worms and Viruses》
Security Corner: Cross-Site Request Forgeries
CAPTCHA项目官网
httpOnly的cookie


感谢阅读此文

        请支持cleverpig发起的image
分享到:
评论
3 楼 cleverpig 2007-02-08  
引用
最近也在关注这问题,,,

因为脚本端估计是没有改了,因为大都会下载到本。

我想在服务端的类里,是否有可能做些控制呢。。。。。

回复摆渡人同学:

十分同意。服务器端安全问题的确应该深入研究一下。
2 楼 摆渡人 2007-02-07  
最近也在关注这问题,,,

因为脚本端估计是没有改了,因为大都会下载到本。

我想在服务端的类里,是否有可能做些控制呢。。。。。
1 楼 codeutil 2007-02-07  
比那些写 stmt.execute(" select * from userinfo where username='"
+request.getParameter("username") +"' and password='"+request.getParameter("password")+"'");

这样的代码安全.




相关推荐

    《Ajax安全技术》PDF

    《AJAX安全技术》是一本为专业人士提供预防Ajax安全漏洞一手实践的入门指导书。众所周知,Ajax具备变革互联网的潜力,但危险的新安全威胁同样随之而来。《AJAX安全技术》揭示Ajax框架与生俱来的安全弱点密集区域,为...

    Ajax安全技术

    通读《AJAX安全技术》你将看到很多用于阐述关键知识点的真实Ajax安全漏洞案例。在书中还讲到保护Ajax应用的特殊方法,包括每种主要Web编程语言(.NET、Java和PHP)及流行新语言RubyonRails。 《AJAX安全技术》一书对...

    AJAX请求是否真的不安全?谈一谈Web安全与AJAX的关系

    Ajax中没有固有的安全漏洞,但是对该技术向量的适配...AJAX请求的安全性是大家经常会谈论的一个话题,AJAX请求是否真的不安全?下面这篇文章就来给大家详细谈一谈Web安全与AJAX关系的相关资料,需要的朋友可以参考下。

    AJAX也有安全隐患.doc

    AJAX也有安全隐患_谈谈AJAX的安全性.doc

    基于Ajax的Web应用安全性研究

    基于Ajax的Web应用安全性研究,欢迎下载

    Ajax安全技术讲解教材

    由于ajax的应用越来越广泛,所带来的优势相信大家都知道,但其存在的漏洞也让人头疼,在这里给大家推荐一本ajax安全方面的书籍,欢迎下载

    ajax安全验证范例数则

    这是关于Ajax的数行代码,希望对大家能够有所帮助,正所谓有福大家同享

    《AJAX安全技术》

    一本为专业人士提供预防AJAX安全漏洞一手实践的入门指导书。众所周知,AJAX具备变革互联网的潜力,但危险的新安全威胁同样随之而来。本书揭示AJAX框架与生俱来的安全弱点密集区域,为开发人员创造安全应用提供指导。...

    通过生成Token解决Ajax请求安全问题AjaxTokenTest

    通过页头生成Token,进行请求验证,解决Ajax请求安全问题。目前为止我做的最多的防止ajax请求攻击的就是添加验证码、添加随机Token,限制同一请求在规定时间内的最大请求数量、服务器端校验数据正确性、尽量使用POST...

    Ajax实战中文版

     本羽阐述了Ajax开发技术的方方面面:不仅全面介绍了Ajax的基础知识,更有对令人高山仰止的架构和模式的深刻探讨,也有潺潺流水般细致的实例展示,而且还涵盖了专业Ajax开发必不可少的可用性、安全和性能等主题。...

    Ajax应用程序安全

    Securing Ajax Applications succinctly explains that the same back-and-forth communications that make Ajax so responsive also gives invaders new opportunities to gather data, make creative new requests...

    Ajax安全技术pdf

    Ajax安全技术pdf

    分析Ajax技术的安全性

    介绍基于HTTP协议传输数据的Ajax技术基本原理和存在...在使用Ajax技术构建的不安全的程序示例基础上,讲解和分析程序实现的过程。例中的程序将捕获和收集在测试网页上所有的操作,并发送消息到服务器上,达到监视的效果

    Ajax安全技术.pdf

    Ajax安全技术.pdf

    一个Ajax表单检测验证实例.rar

    一个Ajax表单检测验证实例,在不刷新网页的情况下对表单中的各个输入项进行检查,并显示出错误提示,在众多ajax表单中,本示例并不是最复杂的,因此对于学习研究类似表单的实现方法很有参考价值。ajax无刷新表单验证...

    Ajax基础教程(扫描版)

    2.6.2 关于安全 34 2.7 dom level 3 加载和保存规约 35 2.8 dom 35 2.9 小结 36 第3章 与服务器通信:发送请求和处理响应 37 3.1 处理服务器响应 37 3.1.1 使用innerhtml属性创建动态内容 37 3.1.2 将响应...

    Securing Ajax Application

    Securing Ajax Application 很好的 AJAX 安全方面的书!

    AJAX实战电子书下载

    本书是目前Ajax领域最为全面深入的一本著作,其中不仅有对于基础知识的介绍,还有对于Ajax开发中重大的体系架构问题的深入探讨,总结了大量Ajax开发中的设计模式,并讨论了框架、安全性与性能等等。书中提供了几个...

    《AJAX实战》AJAX In Action.

    本书是目前Ajax领域最为全面深入的一本著作,其中不仅有对于基础知识的介绍,还有对于Ajax开发中重大的体系架构问题的深入探讨,总结了大量Ajax开发中的设计模式,并讨论了框架、安全性与性能等等。书中提供了几个...

Global site tag (gtag.js) - Google Analytics