腾讯李旬保：WASL-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