WASS全称是Web Application Security Scanner，中文翻译即是Web应用安全扫描器。说白一点就是Web漏洞扫描软件，国外的产品有IBM Appscan、HP WebInspect、Acunetix Web Security Scanner等；国内的产品有JSky、Matrixy、WebRavor等。目前WASS也是逐步升温，厂家也是越来越多。
WASS被广泛关注是有背景的：一来是原有网络和系统漏洞的减少，许多“有志之士”将目标转向了Web应用程序，伴随着大量的SQL注入蠕虫挂马以及由社交网站的XSS蠕虫出现，业界对Web应用安全也是越来越重视；二来，未来的技术趋势也是越来越向Web平台迁移，比如微软和GOOGLE都向网络应用程序和网络操作系统方面演进，这些都是战略性的；最后，从厂商角度来说，利益的驱动还是比较大的，这主要是源自IBM上亿美金收购Watchfire和HP上亿美金收购spidynamics的这几次大手笔。不只是WASS关注度很大，WAF的发展也是很迅速的，不过关于WAF的内容在这里暂且不表。
很长一段时间以来，Web应用安全扫描工具的市场基本都是国外的厂商垄断，国内缺少自动化的评估工具，启明星辰，绿盟等国内少数的几家具有一定规模的厂商在进行安全评估时很大程度上依赖于安全专家，这其实也是有利有弊。因为安全评估不像渗透测试，渗透测试只要找准点攻破目标系统就行；安全评估则在保证有效的情况下还得保证全面性。在这个过程中，人的精力毕竟是有限的，小网站还好，要是来个大网站，上万个目录页面，人力成本是很高的。
再换句话说，即使在有充足的人力成本情况下，你就能保证安全评估工程师不会出现重复劳动下的疲惫或者遗漏？从服务商角度而言也是如此，一个成指数增长（资源增长远小于客户数增长）的企业才是个好企业，一个依赖大量的专家来保持增长的企业就很难想象有多大的发展空间了。再说了，在国内有那么多称职的安全专家？总之，WASS的出现是符合市场需求的，市场就这么起来了，因此国内这几年也出现了像诺赛科技、安域领创还有安恒科技等公司。好歹WASS的市场也呈现百花齐放的景象，越来越多的公司正在加入这个行业。
新的问题就来了，如此多的WASS，如何保证主要功能的完整性呢？或者说对于一个客户而言，如何确保购买的WASS是能够有效的全面的找出系统中的漏洞呢？我们姑且可以认为几个处于霸主地位的WASS厂商也是这么为客户着想的，他们在Web Application Security Consortium的组织下，于一个漆黑的夜晚一个漆黑的小屋内小声的讨论，完成了一份“Web Application Security Scanner uation Criteria”，也就是Web应用安全评估标准，下文中均简写为WASSEC。（稍微遗憾的是，里面没有一个中国厂商参与）
WASSEC可以通过如下地址下载（部分国内用户可能不太方便访问）：http://projects.webappsec.org/f/Web+Application+Security+Scanner+uation+Criteria+-+Version+1.0.pdf，共分为如下几个大章节：
1、 协议支持
2、 认证
3、 会话管理
4、 链接分析
5、 解析
6、 测试
7、 命令和控制
8、 报表
#p#
9、 附录A：考虑购买扫描器时的建议
内容写的比较细，这里并不一一细数，我们也不用太陷入里面的章节。可以从如下框架理解，因为一个WASS无非是满足这些框架功能的组合体：
a. 网页爬虫：评价WASS一个很重要的因素来自于链接分析能力，如是否支持从Javascript中提取链接，是否支持从flash文件中提取链接，是否支持从复杂的ajax应用中提取链接等等。另外也包括标签的事件，重定向请求等。至于认证和协议都是非常基础的，缺少这些的我们甚至可以理解它压根就不是一个WASS。
b. 安全测试：WASS是否有效的核心模块来自于漏洞的分析能力。支持的漏洞种类（SQL注入，跨站脚本，信息泄露等）是否齐全，是否能够准确分析误报（如自定义404页面等），是否支持权限测试等等。
c. 报表：对于采购WASS的用户而言，一份漂亮的报表是必不可少的。是否包含漏洞描述，解决建议；是否满足业界的安全标准（如OWASP TOP 10,萨班斯法案等，这些老外很看重）；是针对开发者还是测试人员；是否支持PDF,HTML格式等等
d. 操作性：对于自动话工具而言，越少的操作达到越大的效果是很重要的，因此像扫描操作，暂停操作等是必须的；同时应当能够及时显示进度，查看已经发现的漏洞细节等。
如果您是一位经常关注Web应用安全的朋友，应该会有一个感觉，这个WASSEC里面有点猫腻。向来咱们中国人都是属于那种闷声做事的那种，尤其对于负责技术的人员而言，对于没有亲眼见着的事情持有很强烈的反对态度。假设我们把场景放在测试人员用工具扫描完然后将漏洞递交给开发人员的时候，开发人员说“这怎么会是漏洞呢，我们一直都是这么操作的啊”，如果这位可怜的测试人员在安全方面不是比较精通的话就很麻烦了。
事实上这种情况并不少见。在我东塔亮看来，合格的WASS必须具备渗透测试功能，否则很难去解释这为什么是个漏洞了。巧的很，咱们国内的WASS厂商都具备这个功能，JSky就不用说了，搭配了包含Pangolin和IISPUTScanner在内的一系列用于渗透测试的模块，在Matrixy和Webravor中也内置了SQL注入渗透测试模块。而这些刚好是国外的WASS中都没有的。看来黑灯下火关门讨论的成果也不是太全面。至少不符合少数渗透测试人员的需求；）
对于本地化来说的话，在WASSEC中也没有提及到。国内的市场需要有本地化语言，这在一些大型采购单位基本都是硬性规定。国内的WASS厂商做的都还比较好。国外的就差远了，像IBM的Appscan采用了自动化的翻译软件翻译出来的语言看起来真是别扭的不行，不过总比没有好，其他厂商的就不说了。
除了本身软件本地化的问题以外，对于编码的支持也是国外WASS所不具备的。比如说，在WASSEC中明确提出了ISO-8859-1、UTF-7、UTF-8、UTF-16编码，对于包括GB2312编码在内的所有东亚或者西欧的编码方式均没有提到，这也就是为什么在国外WASS的一些报表中出现大量乱码的原因。
目前大量网站的表单认证都是带有验证码的，对于一个WASS而言，如何能够绕过验证码继续扫描是一个很重要的技术细节，在WASSEC中也没有提及，我想这是因为与会者所在的那些厂商的产品均不具备这个功能导致的吧。这也是能理解，但是，你们没有，不代表别人没有，这么大一个功能需求怎么就被给“河蟹”掉了呢？
另外我觉得还有一个很重要的因素在WASSEC中是被忽略掉的。大家认为安全评估时只在实验室的调试环境下测试，还是在现网部署的情况下测试下更有效呢？我举个例子，当年中国移动被黑本身官网的应用程序是没有任何问题的，但是不代表第三方程序没有问题啊，更不代表其他虚拟主机没有问题。那么如何去评估虚拟主机呢？怎么知道有哪些虚拟主机呢？这些现网的情况对开发人员而言都是不可知的。WASS应该提供这些手段。
最后，剩下一个最最重要的问题：该份WASSEC并不具备可操作性。为什么这么说呢？从文档的内容来看，读者应当是普通的具有购买倾向的客户，那么从专业性上来说应当是相对较弱的，毕竟不是专业的安全人士。在这个过程中，如何确认文档中的内容对于某个厂商的WASS是否满足呢？举个实例来说，我们对于WASS对flash文件提取链接的能力应当如何去测试呢？甚至能否提取链接都是个未知数，难道客户都得自己先请开发人员做一个flash文件，将不同的链接方式加入进去？这样的可能性基本为零了。到目前为止，没有任何一个厂商或组织发布一份可以用于满足WASSEC中提到所有属性的测试环境。又或者说，该份文档根本就是一个烟雾，只是为了后面出现一个可供具体操作的环境或者第三方测评机构。当然一个不争的事实是，文档的成员厂商是可以堂而皇之的对外宣称他们是完全支持WASSEC标准的，而其他某某某不是。
与国外相比较而言，国内的安全研究人员更利益驱使一点（短视？），很少有人进行大趋势或者技术上的一些总结输出，并且也很少有人体现出“板凳甘坐10年冷”的气魄。这就就是为什么myspace的蠕虫和twitter的蠕虫在国外非常成型且稳定，而国内到目前为止没有一个实际广为人知的社区蠕虫。这肯定不是技术问题，国内在Web安全方面的牛人非常多，技术也很扎实，我甚至觉得国内在Web安全技术方面的研究是超越国外的（我们不否认有国家政策的因素在里面）。我们可以回过头来看看早在05年，美国一个高中生写的MySpace蠕虫的相关技术细节：http://namb.la/popular/tech.html。国内的安全人士是否在敬佩之余也稍微有点汗颜呢？不过话又说回来，国内的这种形势也是好的，技术还掌握在自己手上不是，只是稍微有些遗憾的是，集大成者还是太少。
如今是个科技化的时代，军事战争一部分已经转化为信息化战争。咱们国人也应当多总结多输出。咱们稍微细心一点，是能够发现在WASSEC中带有排他性的，要说排谁，大家只要减去贡献者清单所在的厂商就能得出来。咱们的绿盟啊，启明啊，安恒啊，诺赛啊啥时候也能在某个月黑风高之夜一起讨论得出一个基线标准出来，更适合本土化一点，更专业化一点。毕竟安全类产品国家还是得掂量掂量着引进，这个责任你们不承担谁承担？
总之，未来的Web应用安全有一段高峰期快来了，不管是WASS也好，WAF也好都会迎来一个高速增长期，希望国内的一些安全厂商能够争气一把，抓紧时机，争取出现许多个安全界的百年企业。
【编辑推荐】
