看到技术文章很稀奇——微软安全服务提供专家方兴:Web2.O安全研究

时代变啦:

在WEB旧时代好多站点我们告诫用户你只上你信任的站点,不要上人家发给你的站点,上面可能有挂马。这时候用 户只关心站点,或者你用QQ发一个URL他会标注安全的站点,可能普通用户看见打了勾肯定是安全的。普通用户主要依赖于防范病毒的产品保护来自不可信站点 的攻击。但是在新的时代,安全的站点也不能保证你的安全,因为你通过Web2.0的方式,内容是由很多不可信的用户提供的。所以,用户还要要关心站点的安 全和历史安全信誉。虽然是一个正规的大站点,但是如果连续不断地被挂马,对于这样的站点,用户就应该认为它是不可信的。另外在复杂的体系结构中已不能依赖 原先的保护技术,因为很难防御所有入侵和0DAY,防御动态攻击的内容。 

Windows底层和漏洞挖掘方面的专家方兴就现今Web2.0领域的安全问题与解决方法与到场嘉宾进行分享。

以下为方兴发言实录:

方兴:先做个自我介绍,我叫方兴,以前主要关注的领域是操作系统安全漏洞的挖掘,但是现在我给大家做Web2.0的演讲,实际我是抱着学习的态度,因为腾讯公司作为一个网络,在WEB方面的研究应该比我更多一些。首先我们来预览一下今天讲的主要内容。今天WEB时代的安全与发展风险,相对于以前WEB1.0的时代增加了哪些问题。其次我们来看待它的新的安全需求。最后我们来看它的整个安全发展情况。

为什么我这个题目叫新WEB时代而不用 Web2.0呢?因为Web2.0只是一个开始,只是个时代发展的序幕,它最终的目的是要发展成为取代现代客户端计算的模式。以Web2.0为主要的运用成为了一种趋势。WEB运用逐渐向传统的应用领域渗透,比如我们经常去的Google这家网站。它最终的发展目标就是要把INTERNET变成为数据处理和储存的中心,网络取代传统的OS成为应用的中心:网络既计算机。

这里是一些统计数据(图),关于Web2.0目前的发展趋势。80%以上的基于网络的公司都投资在Web2.0当中来进行开发。在2007年,30%的客户都基于商业上的应用技术。预计到2008年,基于服务器服务构架的SOA会逐步朝着这种模式发展。在当前,安全是WEB向这方面发展的主要障碍之一,因为成为数据和存储处理中心,将会带来很大的安全风险。

在新的WEB时代存在一些什么样的主要特征呢?这些特征又会给我们带来什么样的安全风险?首先,它跟传统的我们以前的WEB时代存在的区别:第一、处理和数据控制集中化,因为它最终目的是把所有的网络计算核心从客户端拿到网络端上。而以后客户机只扮演纯粹的浏览界面的角色,所有的核心数据、核心的处理全部都在网络端。第二、它的内容来源控制分散化,这是当前我们在Web2.0当中看到的最大趋势,以前的WEB1.0是以我为主,比如新浪作为一个新闻中心,我发布了,作为受众来说是被动接受,以前 WEB1.0是核心控制的,但是在Web2.0我们发现草根阶级的应用上来了,它的各种内容不再依赖于核心端来发送,而是依赖于用户主动提供,比如你的博客,你个人提供的各种内容取代了以前核心控制端发布的内容。从数据来源上看它是分散化的。第三、应用网络化。网络应用正逐步蚕食掉现在桌面的应用,而用网络的方式来实现。在这一点上面,以前Google在这方面的表现是最具竞争性的,它想取代微软作为IT行业的霸主,因为作为微软来说它核心的 Windows操作系统已经占有了不可动摇的地位,想要动摇它的地位,只有把所有的应用都逐步换成网络模式,用户就不再需要你的OS,不再需要你的操作系统,他就能真正地从微软的手上取代它的霸主地位,这是它的策略。第四、内容聚合化,因为以前是单一的站点,但是随着未来的发展,信息是逐步交叉的,在 Web2.0上更多地要对内容进行聚合,对不同内容信息来丰富页面,提供更强大的功能。这些特征都将带来新的安全风险。

在处理和数据控制集中化,比如我们的 Gmail,随着Gmail,网络硬盘提供的数据越来越多,都是直接存在网络上,你的操作全部都是放在上面,它处理和数据控制形成了集中化。从需求因素来考虑,首先是数据和处理要集中化,成为计算中心。但是这样会导致一些问题,第一是敏感和隐私数据集中存在,比如以前大家上WEB Mail,商务信件都放在本机。但是现在用Gmail都懒得删除,反正用10G的硬盘,但是你会发现越来越多的敏感信息都放在网络,一旦你相关的邮件信息被黑客攻破,他们就会获得你的很敏感的商业信息。第二是应用越来越依赖网络,一旦网络出现故障,比如台海地震,中国很多的靠进出口加以贸易就会出现损失。再就是大量的海量数据会导致WEB服务器端构架复杂化。

从内容来源控制的分散化,它主要表现在博客、维客和播客上,需求性因素是站点要给用户提供个性化的内容、满足用户的表达和传播需求。它会导致用户和内容海量膨胀,比如新浪有几百万的博客,有几千万用户在上面,每天更新的博客文章数据都是海量增长的。但是,因为它开放了这种平台,导致用户可以在受信的平台上面放置恶意的内容,比钓鱼、木马。用户会认为新浪一个很好的公司,他这个平台上的数据都是可信的,肯定不会做这些事情,根本就不会想到它上面依然可能由于用户提交的内容而存在木马等恶意内容。

从应用网络化的表现,主要表现在 WEBOS,WEB OFFICE等。它需求性的因素是因为网络应用要逐步取代传统的桌面,它要有能力提供越来越多的应用以及应用开发接口。网络最后要取代传统的OS,成为计算中心的话,我们去观察一下以前Windows操作系统为什么能程度一代霸主,因为它提供的很多开发接口,海量增长的应用使得OS极大的满足了用户的需求,用户可以去编写自己或许客户定制需要的程序,未来相信网络要逐步取代的话也会出现这种提供开发接口的平台,允许你在网络平台上编写应用,最后再组合起来。这样会导致比如引入新的技术,比如AJAX技术,对会话状态的依赖,以前WEB1.0对会话状态并不是很依赖。但是网络的应用就要求你本身具备这些复杂会话状态的跟踪和管理。

再就是WEB的应用逻辑会越来越复杂化。无论是服务器还是客户端的代码都会复杂化。另外我们看到浏览器的功能越来越复杂,互相嵌入性的操作越来越多。另外是WEB服务器构架也复杂化。因为网络的后台需要包括数据库等相关所依赖的技术来支持,它会变得很复杂。

内容的聚合化表现最多的就是搜索引擎以及 RSS,需求性的因素是网络需要更多的互动,使其关联与互操作。比如搜索引擎会自动搜集网络上的很多内容,RSS则直接嵌入内容。为了保证访问性还采用了一些CACHE方式,这就导致攻击者可以采用内容聚合来推广他的恶意页面,同时使得数据感染性增强。

我们来着重看一下这四点导致的安全风险。数据保密要求增高之后,敏感隐私数据泄露途径增多,以前可能只存在你的机器上,现在存在服务器上,可以在你的通讯途中被窃取,你保存数据的服务器被攻击,或者是其它的各种方式,都可能导致你的数据损失。另外,你无法保证服务的提供商不利用你的敏感和和隐私数据。这当中最常见的就是朋友圈、MSN朋友圈、QQ朋友圈,他要求你提交用户和口令向你的好友发广告,实际上就利用了里的敏感信息来做非法的事情。

数据依赖会导致安全风险放大,可能影响海量用户,比如信用卡的泄露,信用卡一被泄露都是几百万、上千万的客户受到损害。另外就是DOS攻击和意外事件也会导致大量损失,因为越来越依赖网络的时候,它的拒绝服务攻击的厉害程度,包括整个商务、商业上面的应用影响都会增加。

从内容来源控制分散化带来的安全风险主要是内容不可控性增加,因为恶意客户可以方便的借助受信平台发起攻击,而你没办法进行检测。而且众多的用户提交内容检测困难。另外就是用户不可控性增加,虽然在你上面注册的ID,但是对海量用户的存在进行追查是非常困难的。

应用网络化带来的安全风险。因为应用网络本身就会带来数据的集中化,导致互操作性增加,多域应用,外部内容来源增加,比如BASECAMP是帮助企业做调度和任务管理的Web2.0,但是我们就发现它上面存在不过滤上传内容,你直接可以在里面加上脚本代码发起攻击。用户间的互影响性增加,大家都知道使MYSPACE蠕虫,通过一个用户的版本可以瞬间传递给所有的平台上的用户。再就是程序复杂度增加,以前的WEB应用逻辑大家都知道相对简单,但是随着未来的发展,它肯定要增加越来越多的复杂程序逻辑,才能满足把网络中心变成网络及计算的理念。而WEB应用存在的最大问题是:第一,WEB网络应用未得到广泛的安全测试,因为它大多都是小的厂商,相对来说像微软这种巨无霸能一家完全控制得WEB应用提供商目前是不存在的。比如我们以前说微软的安全很差,但是微软很庞大,所有的技术都是用它,一旦它有决心来改正这个问题,它可以用很多资源把安全作的恨号。Vista用了几年时间就把安全级别提到很高,在2007年,黑客发布的能确定影响到vista的攻击代码只有3个,而XP下面的数据则是30多个。但是对于WEB来说不存在这样的情况,WEB应用的厂商太多。再就是它的开发缺乏安全过程,都是小团队开发,做得好一点的也只是用用一点安全编程的规则去检查代码。另外,Web2.0还是在不断发展的技术,它为了满足前面提到的把计算到网络化,它要不断地采用新技术,增加各种动态性应用的技术。这些新技术会带来新的安全弱点。另外,动态性的增加代码,也会引入很多新的困难。包括对攻击代码的检测,利用时间的动态性、应用的动态性。以前的对恶意页面的反病毒检测,都没办法实时动态跟踪检测,利用这些新技术的动态性,会对检测技术提出很大的挑战。

再一个是浏览器的安全模型会越来越复杂,它涉及到众多的插件,像Flash的as脚本,FLASH是支持脚本操作的,但是由于一经被编译,攻击者可以把恶意脚本放在Flash里导致无法检测。还有跨站和域的安全问题,包括特定的像URL欺骗的问题,这都是我们常规的方法难以解决的安全性问题。引进的新的技术带来的复杂度,会增加安全检测的复杂度,大家都知道,AJAX在页面当中是不用刷新页面,通过AJAX通道动态去获得后台的内容。如果攻击者在运行当中通过AJAX获得恶意内容,然后再对你进行攻击。我们现在有的各种检测技术,特征方面的检测方法都很难检测到这种方式。

这是基于Web2.0复杂的架构(图),在这个图中我们可以看到,WEB2.0的体系结构比WEB1.0复杂很多,而且可以预见:未来为了支持更多的网络应用,会更加复杂。

在浏览器端增加了AJAX、RIA、FLASH的支持,在结构的数据传递上,现在可以做出更加复杂的数据进行传递。在结构上面以前是普通的参数传递,现在可以支持各种RPC的调用以及复杂的数据结构。

从内容聚合带来的安全风险,第一、恶意叶面扩散能力增加,可以利用搜索和RSS把恶意内容嵌入到一个非常有名的RSS或者很前的排名,增加它的传播能力。攻击者还可以利用关键字或者一些恶意技术来获得排名提升能力,比如使用“艳照门”照片提升受害者访问量,使得更多的被攻击者受到感染。有些RSS或其他直接聚合内容,使得这个RSS自身就被感染携带了攻击能力,访问这个RSS的用户也会受到攻击。

聚合导致资源来自多个不同域,控制和检测都存在比较大的困难。另外这个对商业站点的影响性也会加大,我们经常在一些搜索引擎的推广上发现有挂马的现象,它对这些搜索引擎的访问推广站点的商业客户影响比较大,而给这些搜索引擎的商业模式会造成影响。还有是它的感染性和隐蔽性变得很强,大家知道搜索引擎和RSS里的CACHE的功能,一个恶意页面被感染 CACHE,即使原始恶意内容页面被拿下后,利用CACHE的页面依然可以攻击很多用户,很多时候大家都会发现页面访问不到,但是感兴趣的时候还是会打开 CACHE。另一个,攻击者或许可以用这个方式来隐藏自己,用一些比较敏感的、比较受欢迎的关键字,被搜索CACHE之后再把自己蔽掉,利用CACHE去发起攻击,就很难抓捕到这种攻击者。

还有一些其它的问题,第一是流氓越来越多,恶意软件越来越基于WEB进行传播,恶意站点,钓鱼站点越来越多。说到钓鱼站点前几天还看了一个新闻就有一个骗子,他就给很多手机上发一条信息我叫王伟,我的帐号是XX,给我汇钱,结果一个月不到还有人给他汇了八十多万,这就说明就有这么傻的人在,这是没有办法解决的。所以利用钓鱼依然能骗到很多这样的用户。基于网络的这种钓鱼方式成本越来越低,并且越来越容易操作,总有上当受骗的。

第二是流氓成本越来越低,收入越来越高,这是没有办法的,道德的水准跟收入水准成反比。再一个,WEB的经济模式带来的流氓同流化非常严重,也就是说我在另一个群里做站点,他们就谈到,现在你要做站点的推广,你不去跟软件进行绑定,做得再好也没办法获得比较高的流量。所以很多站点的推广全部选择了流氓,这也是我们现在整个安全行业里很大的问题。另一个是利用社会工程发起的攻击会越来越多,鉴别这种社会工程的欺骗比较困难。

前面第一章谈到了目前Web2.0的发展和需求上我们面临的很多问题。接下来我们来看一下它的安全需求。分析安全需求之前我们应该对体系与技术的变化进行一些了解,才能从中看到一些变化。

第一,我们在旧的WEB时代和新的WEB时代进行技术体系与技术结构的比较。在协议上的变化,以前只使用HTTP/HTTPS来识别。在新的里面我们增加了SOAP、RPC等等,在未来可能会增加更多的这样的协议。在信息传递的结构上面,以前是靠HTML的FORM来提交的数据。在现在,随着发展,XML及各种新的数据组织结构越来越多。通讯以前都是同步提交,刷新重定向,现在都是异步跨域,实时通讯。会话通讯能力以前是比较弱的,但是现在由于关联性加强,应用要求对会话的依赖越来越高。在信息交互上以前是单点的信息,现在是多点信息聚合,在一个页面上可能存在着很多的信息流、数据流,和服务器进行通讯。

威胁模型变化:威胁模型评估三个要素:进入点、资产以及受信级别。我们来对比新旧WEB时代。在进入点上,攻击者只有通过入口点才能发起攻击,在以前的时代基本上是很简单的入口点,很容易发现。在新的时代下面存在多种分散入口点,因为现在它通过新的技术在线实时通讯去传递数据,一个页面上可能存在六、七个数据通道。由于网络复杂性,依赖度会增加,也就是说它的数据间的相关性增加了,导致入口点和路径会海量增加。另外是退出接口信息泄露的风险在变高,当程序部分状态改变以后,狠可能一些敏感信息还残留在页面上。

从资产的情况来看,对于安全威胁来说,如果不存在资产,哪怕有一百个可以利用漏洞的也没有安全风险,因为上面没有什么东西值得你关心的。攻击者把你的乱七八糟的东西偷走了你还感谢他帮你清理了垃圾。也就是说当你存着有价值的资产的时候安全才是重要的。随着新WEB时代的应用,商业上的应用会越来越多,有价值是的数据在不断增加的,有些甚至是企业的核心价值所在,因此安全的风险也是在增加的。受信级别来说,以前的受信级别是比较简单的,现在复杂的应用自然导致受信级别机制更加复杂。

从安全威胁的变化来看,从进入点上以前是结构数据入口,现在是多种分散入口,用户场景更复杂,涉及到各种各样要考虑的问题,从依赖上面来看,以前的一个WEB的服务器对外部的依赖度、关联度是很有限的,最多是跟数据服务器有关,现在随着新的技术体系的发展与变化,对海量数据海量用户和复杂应用的支持,外部依赖越来越多,再多信息源的、多协议、多技术体系结构、多种外部相关服务的情况下,配置也会越来越复杂,这种越来越复杂会带来对相关的外界的依赖,你本身可以做到很安全,但是你外界的东西不安全的话一样会影响到你的整个安全度。

从漏洞和利用上来看,以前更多在服务器端,而现在既要关心服务器端,还要关心客户端和关心第三方内容的安全。

从漏洞挖掘的方法学的变化,以前的通道是 DNS,现在直接可以用搜索引擎发现你的后台敏感页面。从漏洞发现上面,以前很容易,通过分析提交数据的结构化来构造测试发现安全问题,但是现在通过 AJAX,它是隐藏在多个调用里,发现困难。而且整个数据流非常的多。以前做扫描器扫描这些漏洞结构化是非常简单的事情,但是现在就要分析AJAX,包括内部的各种状态依赖,然后再去自动地扫描和发现,这是非常高成本的。在逆向代码的分析上,以前只关心服务器,现在更关心客户的安全,包括你的跨站可能会对你的访问端带来的攻击。

这里说明了在新的WEB时代是越来越复杂(图),安全性越来越复杂,需要考虑的东西越来越多。我们前面对比了这些发展,我们可以总结出一些服务器端安全需求的变化。在WEB旧时代只关心恶意攻击服务器的安全,很少关心用户的安全以及聚合的第三方的安全。但是在新的时代要关心服务器端,首先要关心恶意攻击,还要关心用户提交的内容是不是安全的,还要关心WEB的应用代码数据整体关联,比如用户是否能提交一个脚本,然后在其它的用户端进行跨段的欺骗。另一个,他要关心自己整个站点的安全和信誉度。也就是说,当电子商务逐步建立起来之后,长期的安全是用户长期使用你的信心保证。出现风险事件会极大降低用户对你的安全信心。也就是要维持历史一贯性的安全和信誉,需要关注和保护用户,因为商业用户越来越多,客户也是你的资产。像淘宝上攻击者如果利用跨域攻击或欺骗另外的用户信息,虽然对商家的直接影响很小,但是它给客户带来重大损失,导致客户的流失。

所以,作为WEB服务器方提供者,不仅要关注自己的安全,还要关注自己用户端的安全,这些是不是会给你的用户带来危害。另外还要关心聚合的第三方,像搜索引擎需要关心引用和CACHE的内容,以及 URL的安全。关心推荐站点和引用站点的安全和信誉度。也就是说,在新的时代不再是你只关心自己安全的时代,而要关心到所有跟你的商务相关的客体安全。

从桌面端我们可以一些需求变化。在WEB旧时代好多站点我们告诫用户你只上你信任的站点,不要上人家发给你的站点,上面可能有挂马。这时候用户只关心站点,或者你用QQ发一个URL他会标注安全的站点,可能普通用户看见打了勾肯定是安全的。普通用户主要依赖于防范病毒的产品保护来自不可信站点的攻击。但是在新的时代,安全的站点也不能保证你的安全,因为你通过Web2.0的方式,内容是由很多不可信的用户提供的。所以,用户还要要关心站点的安全和历史安全信誉。虽然是一个正规的大站点,但是如果连续不断地被挂马,对于这样的站点,用户就应该认为它是不可信的。另外在复杂的体系结构中已不能依赖原先的保护技术,因为很难防御所有入侵和0DAY,防御动态攻击的内容。

在服务器端要动态有效的管理众多的用户提交 WEB内容和用户,保护复杂的WEB应用不危害到站点和用户,另外还要实现站点的信誉度和安全度评估。在客户端还需要有更好地检测和保护技术,还能预防 0DAY以及新的攻击模式,帮助过滤有害的URL,钓鱼站点等恶意攻击。帮助客户获取对站点的信誉度安全度评估的信息。对于搜索引擎和聚合服务体商需要检测判断恶意URL,需要过滤CACHE页面或聚合内容中的恶意内容,需要对广告和推广站点的内容进行动态实时检测。

当前的WEB各种保护技术是否能保证我们前面提到的安全需求。关于WEB服务器端我们前面提到的几个需求,第一,动态实时有效地管理众多的用户提交WEB内容和用户的安全。用户数据提交渠道增多,为了开放个性化的发展,比如很多Blog都提供了包括允许用户写自己的脚本,写自己各种各样的功能在里面,嵌入很多代码。就目前来说,还缺乏有效检测和管理手段,更多是靠人工举报的方式。

在保护复杂的WEB应用不危害到站点和用户的时候,目前很多厂商还是使用陈旧的保护服务器端的技术,对WEB服务器系统的保护,而很少涉及到应用。比如针对OS和HTTP SERVER作漏洞扫描,对于新的逻辑的构架,这种体系,包括外部越来越依赖各种服务和软件的WEB应用缺乏。现有的针对WEB页面安全的检测,也主要是基于提交参数进行检测,但是应用复杂度使得它的提取参数的技术越来越复杂。另一个,这种应用复杂度带来的新技术引入带来的安全风险。另外,对跨站/逻辑 /欺骗也缺乏很有效的检测方法。对于WEB的安全测试也缺乏理论指导,目前只是简单地利用工具来检查一下SQL注射。但在整个会话性和互动性越来越相关和复杂的情况下,这些检测技术越来越困难难以有效果,因为检测要模拟整个状态,包括登录、操作等相关的过程之后,导致检测模式越来越复杂。更缺乏对交互性应用的检测的方法。而站点的信誉度安全度评估缺乏公正且有长期的跟踪和评估依据。

我们再来看一下当前WEB CLIENT端安全保护技术是否能面对现在的安全需求,在CLIENT的保护技术主要是这样几种,一是基于特征的检测。第二是行为检测,比如攻击之后调用的API的调用,来判断是不是异常的信息。还有一种是提供最小特权和权限控制来进行保护。另一个是提供恶意/钓鱼站点过滤名单来检测。但是,这些技术它都存在着对应的逃避和减弱保护的手段。
比如CLIENT端逃避特征检测。它更多是依赖于已经出现的东西来提取特征进行检测。这种方法是很难检测 0day攻击的。攻击者可以使用HTML/脚本动态加密可以有效地逃避特征检测。还可以使用第3方插件脚本,比如Flash的AS,现在这种很难检测,因为Flash已经被编译了。另一个是动态攻击,比如随机后台判定,动态页面。利用AJAX通道,现在很多检测特征是没办法在运行时来进行判断的。还有就是钓鱼或跨站攻击,你很难利用一个特征去检测。

在CLIENT端逃避行为检测的变化,第一是变化行为,我知道你用这个方法来检测我,我就不使用被检测的行为。再就是用其他类似行为替代被检测的行为。再一个功能行为思路改变:比如只窃取信息而不谋取最后木马种植能力。比如很多很多检测都是对创建进程、创建线程时,敏感操作时进行检测。但是我只窃取你IE当中的敏感信息九就可以绕过检测,还可以利用一些受信程序不被重视难以攻击而不被修补的漏洞来实现一些敏感操作行为。还有一种是利用SHELLCODE来进行对抗,因为行为的检查是滞后,SHELLCODE可以解除检测代码,关闭检测机制/程序,模拟或操纵受信模块来完成相关的行为。

在逃避最小特权和权限控制上面,可以使用提权0DAY,还可以欺骗用户获取授权,比如模拟受信BACTIVEX安装,很多缺乏安全意识的用户就选择了接受。再就是用户态攻击,例如URL欺骗,钓鱼。

在整个WEB搜索和聚合服务安全保护技术上,以GOOGLE和微软的HONEYMONKEY为主,但是在效率和 准确性上还是存在着很多问题。

结论:我们现在面临新的WEB新时代发展的安全需求依然准备不足,没办法从根本上保护WEB服务器端和客户端的安全,无法遏制钓鱼和流氓行为。

第三点是自己的一点想法:新的时代,我们需要整体的WEB保护方案,它能够提供对企业外网和WEB应用,内容聚合服务和搜索引擎,企业内网用户和普通用户都提供完整的保护。要提供多向多角度的来源安全保护。

针对WEB服务器的安全保护,要增加复杂的体系架构的检测和保护能力,增加WEB应用检测和保护能力,例如跟踪会话、复杂的结构和逻辑,加强对新的技术引入带来的新的攻击手段核威胁的研究。增加用户来源内容的检测和保护能力,增加对外部聚合内容的检测保护能力。

这里提一下WEB桌面的安全保护发展。必须要提供运行时可信的检测与保护,应对这些动态和新的逃避技术的攻击,应对0DAY的攻击。另外 就是提供多层次的防御体系,VISTA就是缓冲区溢出的入侵路径上设置了多层次的防御体系来极大的提升安全度的。从未来发展来看,WEB桌面的安全保护和发展应该是多层次全方面的保护,层层阻截,降低危害,最终保护安全的底线。

没有一个技术是能完整保护系统不受攻击的,只有多层防护的体系才能将安全风险降低到可接受的低层度。在下面五个层次都要进行保护(图)。

感谢:知道创宇公司在这方面的一些研究成果

现场问答:

问:您刚才提到可以通过动态加密的方式来进行客户端的检测,我的问题是,这种方式是否有比较好的解决方案?除了运行时的检测是否还有其它的方案?

方兴:如果无法开发出动态运行时检测的方法,那么 可以通过 多 层次的保护体系来阻止,通过层层的阻截。以前一百个漏洞攻击者可以利用百分之百的利用,但是你设置了这些层层阻截的时候,一百个当中可能就只有一个能完全利用了。虽然还有一个可应用,但是攻击者的成本变高了,就意味着攻击者应用它获得更大的利益才是合算的,从某种意义上来说一个攻击者不会用这么高成本的东西去攻击普通用户的,针对有加值的商业用户,成功的入侵与攻击也会明显减少。

问:刚才提到MYSPACE的案例,请问国内有没有类似的攻击情况,以及攻击趋势会不会成为新的攻击趋势?

方兴:国内baidu空间上出现过类似问题,这只是其中的一种趋势。

原文地址:http://tech.qq.com/a/20080318/000329.htm

看到技术文章很稀奇——腾讯李旬保:WASL-Web应用安全的思考

这个主要讲web应用的整体及实现过程安全考虑,文中提到一种叫做wasl的安全体系,最终希望能建立起一套包括人的因素、技术因素、过程因素,组成一个有机的体系结构。说到底web应用的安全主要就是对web设计人员的规范管理上。提倡学习微软在处理安全事件中的一个思想:

微软目前有一个思想,一旦发生安全事件,我们能从中学到什么,怎么规避类似问题。要借鉴这种思路,一旦发生逻辑问题,我们把逻辑最根源问题分析出来,然后会在这上面做很多模型、设计上提一些要求,通过这种方法来做。

下边是引用的原文内容:

来自腾讯的李旬保,在现场发表演讲。以下为文字实录:

主持人:大家都知道Web安全逐渐也被广泛应用了,针对应用层面的黑客攻击也是越来越多了,有没有办法防范外面更加专业、更加体系的攻击呢。下面有请腾讯李旬保给大家带来的WASL-WEB应用安全的思考。

李旬保:大家好,很高兴能代表腾讯参加这次峰会。首先自我介绍一下,我叫李旬保,06年6月从武汉点击查看武汉及更多城市天气预报大学信息安全系毕业。毕业后一直在腾讯公司安全中心从事Web应用安全的工作。这次我演讲的主题是WASL-WEB应用安全的思考。在纯技术更高层面做一点思考,怎么样更好地开展Web安全工作。

这是这次演讲的主要内容(图),首先从现状出发,讲一下现在开发模式的缺陷、WASL体系介绍、应用WASL困难与挑战、最后对Web安全做一下总结与展望。

首先从业务体系开始说起,自从98年腾讯公司成立以来,我们从只有单一的IM业务开始经过9年多的发展,现在已经发展到包括互联网增值业务、无线、互动娱乐、电子商务、广告、网络媒体几大平台组成的比较大的互联网企业。我们的注册用户现在已经有5亿多,活跃用户有2亿多。其中包月付费用户有2000多万。互联网的繁荣也促进了Web应用发展,其中我们有很多业务,除了IM这种是在客户端的,大部分业务都是通过Web来进行的。围绕我们IM平台展开,构成一个比较有机的业务体系。这些应用的迅猛发展给网民带来了很多很好的体验,给公司带来很多利润的同时,我们也发现了很多问题,比如说刷Q币、刷会员、刷天数。去年我们公司就联合公安网监联合打掉了数个盗号、盗Q币的团伙,这个给我们一个信号,除了业务不断创造价值的同时,也有一些反面力量企图从我们这里非法获取利益。我们这个业务体系就像一个网络帝国,它越扩张,它的边界就越大。就意味着我们面临更多的威胁。每一个web门户就相当于进入这个帝国一个城门,一旦一个地方出现了薄弱环节,他就可以通过Web界面长驱直入,到达我们帝国里面。

在现在这种情况下,Web应用安全形势比较严峻的情况下,我们怎么样保卫我们领土呢?首先从 Web安全现状讲起。现在很多人都知道“google hacking”,在我写这个PPT的时候,我想到一个最简单的例子,就是查找有哪些站点配置了目录浏览。服务器目录浏览是一个不安全的配置,我搜索到这个,可以看到还是有不少网站是可以看到目录下的文件,当然这里面只是一个纯粹的网页,好像没有什么发现。但是看另外一个公司,这里面就有一些有趣的东西,打开其中一个文本文件,看起来好像是一些聊天的历史记录。但是这个东西对某些人还是没有很大兴趣。我们看第三个网站,这次我们很有收获,可以看到脚本里写有备份数据的脚本,包括mysql用户名、密码、DB。这里面没有用到特殊技巧,只是用到浏览器就可以看到有这么多东西。而且我们也知道,过去也有报道过这样的问题,把敏感log放在Web目录上,又开放了浏览目录权限,使得黑客直接访问这个目录就把这些敏感的log打开就获取到了明文的用户名、密码。这还是最简单的不安全配置。可以看到这种配置到现在还是很普遍的。如果这种这么简单的安全配置还是这么普遍,可以想象其他更复杂的问题应该是更普遍的存在,也就知道我们现在Web应用的安全是处于怎样的境地。

为什么会出现这种情况呢?这跟我们现在Web业务开发和我们怎么做应用安全的方法有关系。现在是怎么样开发的呢?在国内很多互联网企业都有这样一个特点,就是说业务第一,等有了一大部分用户再完善,而安全呢只是一个锦上添花、可有可无的属性。如果没有时间的话,就忽略掉。如果有兴趣的话,就搞一搞。这在观念、策略上就把安全放在很低的位置。其次很多互联网企业觉得安全就是防火墙,做一下渗透测试。局限于安全技术,但是安全也不仅仅是技术。我们组织上可能有一个安全部门,会响应这些安全事件。外面报告一个漏洞,然后急急忙忙赶回来把它处理掉,这并不是一种有效的安全体制。没有办法从根本上杜绝安全问题以后不再出现,代码质量很难保证。如果不能解决这个问题,安全缺陷数量无法收拢。业务长期高风险运行。有很多业务员会有这样的一个错觉,认为我这个程序已经跑了2、3年,从来没都有出现问题,所以我不用关心它。从来没有出现问题,并不代表问题不存在。总有一天有一个人发现了这个问题,就会造成入侵事故。最主要就是说我们当前这种模式还不能保证Web应用的安全。我们有安全部门,但是在实际中更像一个救火队。哪里出现火情,就急急忙忙赶过去。很多安全界的朋友都经历过半夜被电话叫醒,赶到公司处理安全事件的情况。另外,还有一种情况,互联网应用的开发周期都很短,主要是为了更快把业务推出去。通常采用的开发模式就是一种敏捷开发模式,开发周期通常限制在一个月,长一点也就是2个月到6个月。这么短的时间对安全投入也是大大的限制。不可能像其他做大型软件的厂商可以把几年时间投入到里面去。这样子,开发出来的代码安全隐患是很多的。从里面发生安全事故的几率也很大。一旦发布出去,发生事故后补救的成本也就非常高。并且我们很难从这些事故中吸取教训。

怎么解决这个问题呢?怎么样从根本上解决Web应用安全问题。我们就提出了WASL,Web应用安全生命周期体系。简单来说,Web安全是安全教育、安全技术、安全制度的综合,是一个持续演进的过程,不仅仅局限于技术。这是一个通常情况下我们采用的Web应用开发生命周期图,从业务开始建模然后到它的计划最后到需求,然后到分析设计、然后到编码实现、测试,最后发布版本、部署、上线。这里面就得到一个初始的版本,这个过程又重新整理新的需求,根据用户反馈,新的需求又被更新、设计,加到新的开发计划里去。这是一个迭代的过程。通常一般迭代过程会在2个星期到6个月时间是比较短的周期,每个周期都很紧凑。这是一个分布。从这一个分布得到一种策略,如果我们能够有一种方法,把最多的这种问题解决,我们就收拢了绝大部分的漏洞。然后再对其他的类型,比如说比较难的一些类型,我们通过一些措施能够预防或者降低风险的话,也就解决了剩下部分80%的问题。最后面的,如果很难解决的那些我们就通过其他措施,比如应急响应这些就把所有风险降到最低。我们应该在Web 应用开发周期里用什么样的策略呢?这还是刚才Web应用的开发周期,通过漏洞的简单分析。对于跨站、跳转、注入漏洞这些,大多数都是非常简单的不安全编码疏忽所导致的,可以在编码这个阶段通过使用一些安全编码实践来避免掉。我们对这两种检测也有比较成熟的检测方法可以检测出来,在这个阶段就把它解决掉。而对于不安全配置这种更多的属于服务器配置的问题。这是运营环境了,我们可以在运营这个阶段,通过静态检查以及通过监测方式,把这些问题在这个阶段发现出来。对于第三方合作,可以通过清理的方式,不使用不安全的链接或者使用监视,过一段时间就检查这个链接是否还是安全的,有没有被更改。通过一种报警的方式来解决。然后剩下的是一种逻辑的漏洞,这种是比较难解决。我们可以通过为这些业务在需求阶段提供一些安全的属性、安全的需求,然后在设计和实践的时候把安全需求实现,把常见的这些逻辑问题,比如登陆的身份验证问题解决掉,对于更高级别的逻辑问题,把它的风险降到最低。WASL技术也就是基于这样的分析。

怎么样应用WASL或者说WASL包括哪些内容?大家可以看到右边这个图(图),这里包括几个部分,最高一级就是制度和规范。然后下来是Web应用开发的生命周期,在每一个步骤都会实施这个安全教育,并且使用了相关的安全技术,来保证常见的 Web缺陷能够在成本最低的阶段把它解决掉。剩下的就是漏网之鱼,通过安全相应流程把它处理。这里面第一步是需要定义角色、职责。角色和职责的作用就是说明确你这个组织里面谁应该做什么事情,他对这个事情应该负到什么责任。如果他违反了这个职责,应该受到什么样的处理。一个典型的结构包括管理决策层负责安全制度的决策,然后签署相关的政策文件。专业的安全部门是负责安全技术的开发、研发,然后还有架构的安全审核、安全流程开发、漏洞的响应,这是一个专业的团队。而对于业务部门也同样需要有相应的安全人员。通过设立一个安全专员,他就是负责整个项目、整个流程里面所有的这些安全需求、安全规范,这些措施都能很好实施,并且作为一种沟通和协调的角色。安全接口人是作为业务部门和安全部门起到一个沟通作用。通过这样一个结构,每个人担当什么角色都明确定义出来,这样每个人就能知道具体做哪些事情。角色和职责确定之后,下面也就是安全意识的培养。如果没有安全意识的话,这里面的安全也就是很难保证的。

一个很小的例子,上班路上看到有横幅提醒说请不要使用烟道式直排是的热水器,可能会有安全隐患,这也是安全意识教育的一种形式。这种就是提示你自己会不会也有这个问题呢?我看到整个横幅的时候,就会想家里的热水器是不是直排式或者烟道式,脑子里就有了这样的一种生命安全的意识。还有通过历史案例教育,我们历史上出现的严重问题,它是怎么样发展的、造成怎样的严重后果、为什么会发生,我们会不会在同样地方犯了类似的错误呢,通过历史案例学习可以得到教训。然后针对这个开发生命周期里每个阶段都会会一些针对性课程,比如安全需求怎么提出、安全编码是怎样的、怎样设计安全架构、安全测试是怎么样进行的,一些针对性的课程加深业务人员对安全的理解。安全编程实践主要是通过开发人员,因为所有的实现最终还是通过编码实现,如果编程人员安全编成意识和技术都不够熟练的话,就很难保证安全措施的实现。然后还可以提供渗透实践与演习,我们可以搭建有各种各样问题的一个实践演习系统,通过组织,业务人员来参加这个实践的演习,让他们能够从黑客这种角度怎么样通过这些漏洞入侵到系统里,加深他们对Web安全的理解。而这个教育过程要持续进行。并且这个教育还必须有一个体系来确保达到相应效果。我们可以通过考核或者一些激励措施,相当于安全知识的认证。比如你每年都要通过一个考试,能够达到这样一个水平,然后才能继续开发。

一旦进入开发周期了,最开始在需求这个阶段就必须得把安全需求提出来。这里面安全需求的提出可能由业务这边来提出,这就需要业务人员、需求人员也有一些安全的意识。就是说我这个业务哪一些东西需要保护、哪一些是最有价值的。如果我这个业务有人非正常使用的话,比如误用、滥用或者一些异常使用的话,他应该是怎样的应对。在开发过程中,还可能有需求变更的情况。如果需求变更了,对现有系统有哪些影响。这些都需要在需求这个阶段确定,并且要保证安全需求能够持续得到跟踪,主要通过安全专员来确保。

到了设计这个阶段,通常就是包括了架构设计和模块的设计,这里面对于设计的话,也有很多的很好的实践。但是在架构这一层显得有一点点虚,比如说保持简单,大家都知道越复杂的东西就越难实现、也越难测试、也越难保证它是正常工作。但是通常很多业务都复杂,在复杂性和安全性、简单性得到一个平衡。defense in depth,每个步骤都要进行适当防护,只有加强了最弱的链接,整个流程才是安全的。在操作某个资源的时候,你需要给他最小的权限,只需要读的话,就不要给他写的权限。还有信任原则,既使是内部系统,也要坚持最小的信任原则。可能你信任它,但是它这个可能是一个不安全的来源,输入到你这个系统之后,就变成一个危害。Graceful Failure,就是一旦失败的时候,要恰当处理失败的情况。比如有一些业务支付失败,支付到一半的时候应该怎么处理呢?是重新执行一次还是完全拒绝这次服务,让用户重新开始,这里面都是要考虑的,否则的话有可能在这个过程中出现问题。

怎么样设计一个安全架构呢?它的策略有哪些可以参考?这里面提到最开始你要确定这个系统里面有哪些资源。有哪一些角色,然后这些流程通过的边界有哪一些。明确资源、角色、边界,之后你就可以对不同的资源提出不同的安全需求,也就是从需求这个里面来,然后为他提供不同程度的保护措施。当这些都确定后,可以设计一个最简的方案,包括安全的措施。并且在这个过程中设计一个验证的方案。也就是我怎样验证,这些安全措施都得到了恰当的实施。在这个阶段可能还需要做一个风险分析,就是这个应用一旦部署之后他会面临哪些安全威胁。这个主要通过几个步骤来,首先是需要分析运营环境中有哪些安全因素,是网络这一层还是应用这一层,还是合作方这一层。确定最有可能的威胁,哪一些威胁是最严重的,最有可能发生的。一旦发生之后它的影响会有多大,它发生的频率有多高。一旦这些清楚之后,我们就可以制定降低威胁和风险的措施。当这个架构设计好之后,通常应该还是经过一个验证、评审阶段,对于每一天开发的,不需要这么频繁的安全评审。但是最初建立的时候,这个时候需要安全评审。还有在架构进行重大调整的时候,也需要评审,这个重构会不会对现有架构产生新的威胁。

这是一个简单的模型。上面一层是Web浏览器,下面是Web应用,左边一个站点A、右边一个站点B,左边这个站点A是一个典型的二层架构,右边这是一个典型的三层架构,对于这样一个架构怎么样分析它的威胁,哪个架构更安全呢?为什么说三层架构要比两层架构安全一些呢?我们可以通过分析它的威胁来得出它的一些结论。在哪一些地方可能出现问题,对于两层这种应用来说,首先数据传输要经过信道,这里无论两层还是三层,他都会要经过这个信道,然后进行一个从浏览器到服务器端的交流,而这个通信信道有可能受到的威胁是是被监听,可能会导致敏感信息泄露。而这个威胁对你应用威胁有多大呢?一般应用是无关紧要,可能就是一个通告。但是对某些应用要登陆密码或者在线支付应用,必须保证整个通信过程都是安全的。这里面是一个威胁点,面临的威胁就是被窃听。在CGI这一层,从外部处理数据,没有验证参数,对客户端软件可能会溢出。这种威胁情况主要是在于可能会造成拒绝服务的攻击,再到数据这一层,可能会受到系统注入的攻击。在登陆这个步骤里,很有可能CGI没有进行身份验证然后就允许你访问一些敏感资源或者是你的身份级别不够,某些资源是需要、某些级别需要会员级别才能访问,但是我没有判断完全就允许你访问这些资源,那也是一个逻辑的问题。这可能会在逻辑模块出现。

三层架构多了一个APP,APP把DB请求转换。这里面主要威胁是在于因为多了一层从CGI 到APP就多了一个边界,这个就存在一个信任的关系。认为内部可以任意访问,这种情况很常见,就是说A部门系统有一个资源类似于IM,B部门有一个业务需要访问IM资源来提供相应服务,IM部门提供一个接口给提供Web服务的部门,但是要充分信任Web应用这个部门,这样就使得Web部门也没有考虑到这种情况,一旦发生不验证你这个身份然后就操控了其他用户的数据,这种情况也是会有发生的。但是如果我在这个阶段就限制了,把信任关系降到最低,不信任CGI 这边,要验证你的数据,这种情况就不会发生。多了一个逻辑层之后更有可能发生逻辑漏洞问题。因为Web应用是无状态的,他如果要维持一个状态的话需要一些比较复杂的逻辑。这个过程很容易出现的。Web应用最关键的还是业务,业务逻辑一旦出现问题,有可能会造成很大的一个损失。这是在服务器端。

在客户端又有哪些威胁呢?表现层常见的就是钓鱼,也就是一些虚假诈骗信息。这个也属于Web安全范畴。这个跟漏洞有比较小的关系,但是也是严重的问题。因为很多用户经常会受骗,这个信息从我们站点里面出来。然后在客户端这个逻辑有可能会受到身份被盗窃。也就是说用你的身份来进行一些操作,比如说我用你的身份帮你买一个东西或者给谁发一个消息,帮你投一个票,但是你完全不知道,这种漏洞主要是利用跨站脚本、CSRF攻击。还有恶意代码,恶意代码怎么会从我们这里出现呢?主要是有一些应用我需要允许用户输入HTML,比如电子邮件、 BBS,有可能你的应用某一个地方出现跨站问题,他就把恶意代码就放在这个地方来,一旦用户访问的时候,就会使用户遭到一个攻击。在架构上要考虑怎么样消除这些威胁。三层架构为什么比两层架构安全些呢?因为三层架构可以在APP这一层做一个集中控制,而且有一个审核机制,就比一个这么多的入口安全很多。主要是看应用的需要。两层架构最主要是要守住门户,也就是编码层次,要安全的编码。这样就不会触及到DB这一层。

之后就是实现,也就是编码。始终要贯彻安全的思想,比如占绝大部分不安全的编码主要是 code注入这些,还有跨站脚本出现,跳转、读取文件这些,这主要都是参数验证,这个都可以通过安全编码指引。使用安全组件的话,可以把一些常见的工作用组件实现,减轻编码人员重复编码的工作。对于这些安全的需求、实现,要提供一个测试标准。就是怎么样测试代码。在这个阶段可以提供一些工具的支持,比如静态代码分析,可以分析一些code注入、跨站脚本,同时可以提供一些脆弱性测试工具。在这个阶段还要进行code review,重审代码,把残留的不安全代码清理掉。

测试,测试这个阶段需要为安全需求创建测试策略和用例。主要要测试安全特性,通常我们会有一些比较有规律的一些测试案例,通过总结历史案例用自动化测试工具,还有通过人工测试某些关键地方,然后把这些问题找出来。在这个阶段进行单元测试的话,是比较好进行的。因为可以有自动化工具进行,但是系统测试的话就稍微困难一些。因为系统测试需要整个业务结合在一起,而且还有可能很多地方是不到的。系统测试可以发现结合在一起出现的问题。自动化测试主要是不安全代码的测试。测试之后就是发布和运营阶段,这个部署之前通常要确保运营主机环境安全,主要是一些配置。还有通过这些相应的扫描工具来进行复查,在管理中主要的情况就是比如说某些需要创建DB连接,需要用低权限用户,还有管理后台权限。曾经发现有些问题是把管理后台开到外网去,而且这个用户的控制存在弱密码的情况,这种情况也需要考虑。通过在线监控和扫描可以发现这些普遍性的问题,存在的漏洞都可以发现。对于一些入侵的话,也可以进行某些告警。文件被篡改的话是可以被发现的。对业务异常信息监测与分析。

迭代,在某些开发中,迭代是非常频繁的。这里面主要要注意需求变更的时候,安全需求也能够得到相应的关注,保证这些需求满足新的需要,通过持续的重构,可以把旧有的不安全的代码清理出去。在这个阶段还会有持续集成、灰度部署策略。持续集成是在每一个小的阶段测试每一个小的单元,把安全问题解决掉,避免它集成到大的系统中后很难修改。灰度部署的时候要确保不同版本的边界,没有出现版本交叉带来的安全问题。

通过前面几个安全开发周期的相关策略,基本可以消灭大部分的安全隐患。但是还是可能会存在漏网之鱼,那就是要通过安全响应来进行善后处理。主要是经常监视这些漏洞的来源,是来自外部报告还是内部渗透测试。还是被一些地下组织利用。不同来源有不同的响应策略。漏洞发现之后要分析与定位,到底涉及哪些系统,发现的问题是在哪个地方,然后制定修复计划。并且进行回归的测试。确保没有问题之后再重新发布上线。如果一旦这一个漏洞已经被外部公布的话,还要采取措施应对公关危机。最后我们要从这些事件中吸取教训,避免以后重犯同样的问题。

安全技术,包括代码审计工具,对一些常用的过滤库可以通过提供安全组件与API库形式。对测试也可以有CGI测试工具、漏洞扫描平台,其它的安全技术包括敏感操作行为分析、第三方内容监控、配置核查等。

这是一个图(图),从最底层网络层端口扫描到主机层的漏洞扫描系统,确保这个主机没有开放不允许的服务。CGI扫描系统保证应用程序没有问题。对于第三方的可以通过一些监控,检测文件是否被篡改。在内部的可以实现一些防篡改的措施,比如监控主机文件有没有被改变。通过这样一整套系统基本上可以使我们安全水平达到比较高的层次。对于安全API这些还可以进行Log,给我们提供攻击数据分析来源。比如现在的攻击趋势是怎么样的。所有这些系统都接入ITIL系统里,一旦发现问题可以及时通知到负责人进行快速响应。下面这个是在开发流程里应用到的技术,主要是编码阶段的安全API,开发阶段有静态代码分析以及开发和测试时都应用到的安全测试工具。

安全的制度,这需要高层的理解与支持,对安全做一个承诺,没有制度的支持,多好的体系都是空谈。规范与标准的作用,相当于一种指引,而流程则提供了规范实现的途径。最后有了制度之后,还要切实地执行。这是WASL体系总结(图),最高层是安全制度,然后通过规范、流程、标准指导,最下面就是教育、技术、实践、执行。这个体系里面包括人的因素、技术因素、过程因素,组成一个有机的体系结构。

困难与挑战,主要还是制度的建立。需要在不同的业务模式中进行成本与收益的平衡。体系的建立,需要所有人员的理念与习惯做出一定的改变。在队伍建设方面,需要普及安全知识与意识,并培养一定的安全专家。技术上的难关,可以通过众多的企业进行开放与联合,共享相关的安全成果。因为安全技术毕竟是一种知识性、基础性的东西,大家可以共同合作的方式,把安全推进,从而使各自的业务能够集中精力,提高整体的效率。

WASL展望:安全技术不断进步,黑客也不断进步,可以预料是一个长期的攻与防的过程。我们需要探索出更规范更有效的体系来指导实践。在软件安全体系方面,业界已经有一些比较好的体系,可以适当的进行融合。最后,希望业界中能够有更多的交流互通,集合众人的力量来共同做好安全工作。

以下为现场问答:

问:我有一个问题,你这个体系做下来已经基本上杜绝了sql注入。但是有一个问题,业务逻辑上面怎么检查?

李旬保:目前这方面还是比较少经验,可能需要更多从一开始需求的时候提出一些安全需求。比如一个Web IM我在登陆的时候,因为它登陆模式不一样,我登陆的时候能登陆到我自己这个,我给别人发消息的时候,不能匿名给其他人。

问:我是这个意思,能不能有效检查这些?我们现在发现一个可以修补。怎么去检查这些问题?

李旬保:目前还没有太多有效的经验。

主持人:对于CGI这种逻辑问题可以从几个层面解决,第一,从初始的设计方面。比如充点卡,你在CGI开启的时候就是写死,把消息分得很清楚。可以有利于避免逻辑。这只是一个层面。第二,DB。刚才他提到的也是目前比较有效的方法。根本解决方法无论什么安全目前都无法解决。微软目前有一个思想,一旦发生安全事件,我们能从中学到什么,怎么规避类似问题。要借鉴这种思路,一旦发生逻辑问题,我们把逻辑最根源问题分析出来,然后会在这上面做很多模型、设计上提一些要求,通过这种方法来做。我认为第三点很重要,本身在企业内部要有一个数据库,然后去研究它的根源是什么,这样才是最高效率的。

李旬保:比如我充值的时候,会充一个负的数或者很大的数,或者要充值提交这个请求的时候把帐号改掉。

问:我的意思是这样,两个业务,可能A部门设计这个点卡充值30元,B部门推出一个15元的,导致这个业务就变成可能双方都不知道的情况,产生业务逻辑的错误,而不是程序上的。程序上的我们都能规避,但是在业务上,特别是检查发现存在很大问题。我觉得代码注入都可以有一种方式去检查,这种逻辑上有没有一个好的手段?

主持人:这个问题跟我们提供的一个方案比较类似,方法三,模型。再一个我提到的设计这块,统一调一个bos接口就可以解决。今天我们的会议十个精彩议题都已经演讲完毕了,首先感谢李旬保。相信大家从中获得了不少有用的信息。感谢专家们的演讲,同时也感谢各位积极的交流与提问,下面有请安全中心经理为我们会议总结发言。

安全中心经理:首先非常感谢各位专家的精彩演讲。专家用非常丰富的经验对安全趋势研判给我们非常大的启示,在座也大受菲益。各位会问我们为什么办这样一个峰会,前一段时间发生了一个攻击事件,包括google、新浪、百度,他用大量肉鸡攻击网站授权服务器,然后在一个假的网站上放了很多漏洞,比如迅雷、暴风影音,上面挂了很多木马,这个木马就是偷中国26种游戏密码。从这个案例我们就可以看出黑客行为无时无刻不在进行中,我们互联网企业经常也都是孤军奋战,我们办这次会议不仅是提供一个交流平台,更希望建立一个联系渠道,在比较

原文地址:http://tech.qq.com/a/20080320/000266.htm