Web应用程序安全趋势

Web应用安全引言

Web应用程序的高速增长直接导致了相关安全事件的增加。现在，Web应用安全正受到越来越多的关注，并且在安全事务中的优先级也在不断提高，但是在技术领域仍然存在一些阻碍。这篇文章汇集了有关Web应用程序安全在技术和商业方面的趋势。

网络层与应用层的融合

通常意义上的风险评估和管理主要针对网络层或者操作系统层，利用手工***测试以及一些自动化安全评估工具来完成。当下的发展趋势上倾向于网络扫描器与应用层弱点扫描工具的融合。前一阶段赛门铁克收购@Stake可能不仅仅是为了获得@Stake在服务领域的生意，还看重了@Stake丰厚的技术积累。我们将同样在网络管理软件领域看到类似的融合。

现在大多数网络管理终端适用于类似防火墙这样处理信息请求的设备。未来的发展趋势是将除网络层之外的各种应用层处理工具（例如应用层网关）整合进来。一个没有明显体现出这种趋势的领域可能是补丁管理系统。虽然网络管理软件的控制台能够与补丁管理产品进行良好的捆绑，但由于很多Web应用程序是公司某个部门自行定制开发的，所以在这种情况下很难将网管软件与这些Web应用的对接，而只能由其开发者手动进行漏洞修复等工作。

QA测试和开发知识

通常，QA(Quality Assurance)小组并不与信息安全人员为伍，但是有趋势显示了这种思维正在转变。自动化测试工具领域的主导厂商Mercury Interactive最近宣布与一些主要的安全检测供应商合作，提供自己测试产品与其检测工具的整体解决方案。

这意味着QA小组要成为安全专家？并非如此。整体解决方案允许QA测试人员继续完成他们的自动化测试，而无需了解相关的安全技术。在大多数情况下我们将看到企业根据自身的安全策略创建相应的自动化测试，并由QA专业人员来负责执行。

我们期待看到QA小组的工作从功能性测试向符合性测试扩展。举例来说，为了符合不同地区的隐私法案，QA小组可以决定哪些Web页面需要提及隐私政策，以及哪些页面应该在表单的提交中透漏URL信息。

开发人员也将受益于不断发展的的Web应用程序弱点检测工具。理想情况下，检测系统能够从有缺陷的代码行中找到安全漏洞，这种功能可能会象代码编辑功能一样成为开发工具的基本组件。一些厂商已经开始为提高代码安全性推出相应的开发工具，但目前这些工具的销售情况还不是太好，因为大多数这类工具不能提供完整的应用程序理解能力，而只能针对特定的模式进行操作。同时我们可以预期集成Bug追踪系统的出现，这将简化开发人员现在所使用的缺陷跟踪方法，并使开发人员可以象处理功能缺陷一样简便的处理安全缺陷。

进阶的行业知识

这里汇集了一些技术方面的信息以供大家增进Web应用程序安全弱点方面的知识。至于到底哪些资讯渠道对于商业产品开发更具影响力目前尚未有明显的结论。

下面是两个在应用程序安全技术发展方面起到关键作用的组织：

l   Open Web Application Security Project (OWASP) – 做为最权威的组织之一，发布针对主要Web应用程序安全漏洞的Top Ten列表。

l   OASIS Web应用程序安全技术委员会 – 发展将Web应用弱点及***进行分类并生成XML schema的技术。

Web应用程序安全检测技术能够为边界防御设施（如防火墙和***检测系统）提供更为广泛的检测能力，不同的标准和厂商联盟也将因此产生。目前比较优秀的标准包括应用漏洞描述语言（Application Vulnerability Description Language）和Web应用安全（Web Application Security），两者都基于XML标准。

从微软发布的安全信息也能获得丰富的知识，这一点已经开始迅速在开发社区中获得认同。另外象美国信息技术协会（ITAA）这样的行业组织，预先为离岸的程序提供Web应用安全方面的指导，很多离岸的公司也努力提高其产品的安全水平以为他们的客户提供更好的服务。

***检测精度的发展

Web应用漏洞检测技术变得日益精细起来。大多数工具的发展已经超越了通过指纹识别简单缓冲区溢出***的阶段。对于呈增长趋势的跨站脚本（XSS）***，一般的方法是使用内嵌检测的方式进行处理，并且检测方法正从简单的内嵌字符串注入检测发展为多层次的***检测。复杂之处在于对性能（Web应用和用户输入产生的交互所用的海量数据）和精度（减少误报）的处理。对于一些大型金融机构最近揭示的跨框架脚本（XFS）***，一种特殊类型的利用页面中的框架技术的网络钓鱼方法，厂商也及时对检测方法进行了更新。

Web服务是另一个受到关注的领域。当更多的网站和在线应用程序依赖Web服务的时候，我们迫切需要对Web服务的安全弱点进行检验。在极大程度上，厂商只是利用一些简单的技术检测畸形XML schema***，并将现有的非XML应用程序弱点知识应用于XML应用程序。在这一领域仍有很多工作需要完成，这决定了我们的商业应用能否信赖Web服务。

检测工具的增长

包括用户创建自定义测试这样的新功能正被加入到工具之中，以提供为新的安全弱点编写脚本的能力。传统模式下我们通常从厂商处获取程序更新，一般需要六个月到九个月的时间 – 相对于信息安全世界的变化来说这实在是太过缓慢了。一个关键的挑战在于这些策略脚本采用怎样的格式，目前VB、javascript和Nessus的NASL语言正被厂商广泛使用。很快，定义和设计得更加完善的检测工具将可以选用更多的脚本语言，并有效的将开源工具融入商业程序。

风险评估工具的最关键的能力并不仅仅是***能力，更在于如何快速的获取新的***方法并成功的检测这种***。另一个衡量Web应用程序测试工具的重要尺度是所能发现漏洞的数量以及产生的误报数量，误报使我们必须付出巨大的努力手工过滤数据中的虚假内容。

主流的***检测工具也象传统的故障检测工具一样由简单的模式匹配（例如搜寻404错误页面）向更加复杂的检测手段（例如用户配置的规则表达式）演化。未来的趋势在于发展启发式检测技术，近年来涌现的zero-day防御技术从已知安全漏洞的行为中学习其模式并在未知行为的检测中进行应用（现在一些***检测系统使用了这样的技术）。

目前大多数高阶的安全测试人员使用包括商业和开源产品的多种工具来完成工作。主要的理由在于大多数工具只能发现已有漏洞中很少的一部分。按照我们的经验，大多数工具在检测典型Web应用程序的时候至少应该发现已知漏洞的25-50%。一些厂商允许用户增加自己的脚本以对产品进行扩充，这有助于增加能够发现漏洞的数量，也能减少误报的发生。显然，象检测技术的发展一样，产品的精确性也将持续得到改善。其间用户应该关注更重要的需求，正确的评估工具的弹性和扩展能力。

另一个有待成长的是对于Web应用程序客户端的测试能力。大多数站点非常倚重javascript技术。然而现在很少有工具能够妥善的对类似javascript这样的客户端脚本进行测试和处理。对厂商来说这个问题或许非常困难，因为在编码风格方面大家所受的训练存在着很大的不同。因此，面对弱点检测工具中需要内建代码扫描程序的需要，产品供应商们面临着不小的挑战。

结语

目前大多数Web应用安全测试工具仍然集中在***测试人员和安全专家的手中，但已有向QA工作人员和审计专家扩展的趋势。我们的一个美好远景是所有开发人员都能够肩负起编写安全代码的责任，安全永远是一个整体，需要所有相关的人同心协力构筑良好的防御。