前些日子的安全事件大多与Web应用程序密切相关，许多单位和个人也由此看到了采取必要措施防护Web应用程序安全的重要性。笔者觉得有必要在采取防范措施之前先对自己的系统进行一次严格的渗透测试。因为一些专业的应用程序渗透测试工具和服务有助于防止自己的网站变成黑客和恶意软件的桥头堡。
有人认为单位的网站有了Web防火墙的保护就不需要其它保护措施了。这是错误的，因为最近的攻击以及将来的攻击将越来越依赖存在于Web应用程序中的缺陷，这些缺陷通常都包含着易于被利用的漏洞。据有关数据统计显示，如今多数支持外部访问的应用程序都是基于Web的，而其中的多数又都包含着可被利用的漏洞。
所以，在将Web应用程序推向实际使用之前，最好先借助Web应用程序渗透工具测试一下。目前，这类工具多数都可以执行Web应用程序的自动扫描，它们可以实施一些威胁模式测试，从而揭示一些常见的漏洞，例如许多程序可以揭示Sql注入式攻击漏洞、跨站脚本攻击等。有时，这些工具还可以提供一些参数供用户修正所发现的漏洞。
用户需要在攻击者实施破坏之前先对自己"狠"一点。当今的Web 渗透测试已经被多数机构看作是一个保障Web应用程序安全的关键步骤,这种安全测试已经成为机构风险管理的至关重要的部分。否则，单位就是将这种"测试"拱手交给了黑客。
而如今的安全测试市场并没有绝对的标准，所以有必要探讨一些评估和使用这些工具的服务和方法。(本文所涉及的Web应用程序渗透测试工具也指Web应用程序扫描工具)
三个要素
1、使用者：
由于其复杂性，将保障Web应用程序的安全性的责任分配给适当的人员并不是一件简单的事情。对开发人员和咨询人员来讲，这可谓是一个新的概念。安全管理成员也许更熟悉网络问题，而不是应用程序问题。那么，谁来做这件事情呢？笔者认为，由安全专家们实施测试，然后将结果交给开发人员的做法并不明智，甚至难以实施。不过，这正是目前许多公司正在使用的方法，至少在开发人员乐意使用这种工具之前是这样的。
如有的信息安全专家就承担了Web应用程序安全的责任，他们相信维护和保障企业网络安全最终是他们的责任，所以不必由应用程序的开发人员解决漏洞问题。如果开发人员说，不要紧，我检查一下，应该没事儿的。你怎么办呢？
试想如果我们将测试工具将由开发人员使用，他检查出来的安全报告篇幅又较长，还不把他们给吓坏了？实际上，安全团队可以帮助开发人员使用这种工具。安全人员由于具备了专业的知识和技能，也就能够区分安全问题的优先顺序和严重程度，并可以编辑这些报告，从而便于开发人员实施修正措施。如果由开发人员自己解决这些问题，如果发现了200个问题，他又如何判断哪些是高风险的漏洞，哪些是低风险的呢？
所以，先要决定这种漏洞扫描程序给什么人用的问题。
2、这种扫描的性质:
也就是要看它是一种工具还是一种服务？用户可以购买相关工具，并投入资源来打造一个强健的测试机制，或者通过一个厂商来远程扫描企业的Web应用程序，验证所发现的问题并生成一份安全聚焦报告。但由于控制、管理和商业秘密的原因，许多公司喜欢自己实施渗透测试和扫描，但专业的扫描服务将会不断发展壮大。
公司也可以选择兼而用之。如有的安全管理人员自己先不使用安全测试，而是委托其它的专业厂商进行。特别是在发现自己的公司并没有这方面的专业人员来管理安全测试所生成的海量数据时，这应该是一个明智的选择。否则，企业会发现受到许多似是而非的东西的影响，并不能得到真正漏洞的完整报告分析。企业可以求助于专业的公司分析测试结果，并与开发人员协商来修正问题。在逐渐熟悉这种服务或工具之后，企业可以扩展这种工具的使用，并且可以采取一种三步走的方法。第一步，开发人员测试代码，并与安全测试厂商协调。第二步，安全管理人员用安全测试工具进一步测试程序。第三步，将应用程序推向互联网，由专业的测试公司或工具来实施测试。
3、如何整合？
这些工具在通过本地化方式或通过应用程序接口（API）与开发人员或咨询团队所使用的其它系统整合后，运行起来将达到最佳状态。如与内容管理工具、项目管理工具等工具的整合，从而也便于跟踪并修正其它方面的代码缺陷。如与微软的可视化开发开台Visual Studio.net的集成，就可使开发人员从其桌面上执行扫描，它的使用界面类似于其开发工具的界面。
最好的工具应当能够将结果直接导出到一个静态代码扫描工具中。这正是Web应用程序测试工具可以告诉用户是什么性质的漏洞，但却并不查明代码中是哪个位置有问题的原因。
