产品经理眼中比较理想的 WEB 扫描器

2017-02-14 09:37:00

摘要

漏洞扫描器，也叫VA（Vulnerability Assessment）漏洞评估或者VM（Vulnerability Management）漏洞管理，一直是各大安全厂商产品线中不可或缺的一部分。本文是以一个产品经理的角度讨论其中更细分的一个领域，WEB漏洞扫描器。所谓产品经理的视角其实是兼顾甲方和乙方的立场。

重要地位

WEB漏洞扫描器主要任务是发现WEB服务存在的安全漏洞，及时通知用户并给出一定的修复建议。在PDR以及P2DR模型中，WEB漏洞扫描器属于检测环节，是动态响应和加强防护的依据，通过不断地检测和监控网络系统，来发现新的威胁和弱点，通过循环反馈来及时做出有效的响应。当攻击者穿透防护系统时，检测功能就发挥作用，与防护系统形成互补。在SDL过程中，WEB漏洞扫描器的一大作用就是在上线前在测试环境对业务系统进行安全扫描，发现WEB漏洞。

常见衡量标准

如何衡量一款WEB漏洞扫描器能力是一个非常复杂的问题。Gartner的观点主要是以下几点：

对设备、第三方运营系统及应用的覆盖范围广度；
漏洞签名和相关通告的范围和质量；
扫描机制的速度、可靠性、易管理性和安全性；
分析和报告发现结果的能力；
漏洞数据管理和跟踪能力；
集中化管理和扫描器扫描调配能力。

实践中的不足

市场上的WEB漏洞安全产品十分丰富，从开源工具到免费SaaS产品和商业产品，几十款肯定打不住。我在实际工作中也接触了很多，以比较严格的标准看，或多或少都有以下问题：

对API服务支持差

随着移动APP的快速发展，WEB服务迅速的从单纯的PC浏览型网站迅速过渡到APP API服务和PC浏览型服务并存，甚至部分网站只有APP服务了，主页就是个公司简介加APP下载。大多数扫描器没有及时适应这种新变化，大量API服务无法被扫描器的爬虫爬到，这导致扫描器几乎失效。

爬虫能力偏弱

即使是针对PC浏览器网站，由于js以及大量前端开源框架的快速发展，传统的爬虫面对静态网页和简单的动态网页尚可，面对较复杂的动态网页就很吃力，出现大量链接爬取漏掉，也直接导致了扫描器的大量漏扫。这两点真正使用扫描器的甲方多有体会的。

自动化能力弱

这里的自动化能力，主要是指自动发现扫描目标的能力。绝大多数扫描器需要用户手工录入扫描目标，这本来也无可厚非，但是在实际操作工程中，梳理清楚自身IT资产这本身就是一个十分繁重的工作，而且IT资产本身又是个时刻动态变化的，即使是支持批量导入，也不能完全解决问题。我之前遇到过一个CASE，某个互联网公司测试态势感知类产品时，运行了近一个月后发现一起真实入侵，被入侵的域名OP查了半天也不知道是谁的，最后打了一通电话后才知道是个RD的测试环境，当时的OP离职忘交接了，当时的RD也离职了。幸亏是测试环境，也没造成啥影响，不过从侧面反映出互联网公司的IT资产管理的困难。在这种实际情况下，指望手工维护和录入扫描目标，几乎是不可能完成的任务。部分扫描器在安装客户端的情况下可以很好解决这个问题，但是这又引入了另外一个问题，全量部署扫描器的客户端这本身又是个很困难的事情，尤其是在中大型的公司。

缺乏基础的业务安全检测能力

这里的基础业务安全的检测能力，我其实也不太确定是否应该是WEB扫描器来做，不过在它上面做确实挺合适，就是个顺手干的事。所谓的基础业务安全的检测能力指的是：

暴恐，涉黄，涉政，违法广告
主页篡改
黑色SEO

信息孤岛难以融入安全体系

多数扫描器还是信息孤岛一个，与其他安全设备没有协同联动，与内部工作流系统没有对接。

理想中WEB漏洞扫描器

安全技术这几年发展很快，我觉得在未来两年内可以完全做到以下几点还可以算上比较理想的WEB漏洞扫描器，再长点的时间就不敢说了。

多数据源支持

扫描器可以处理的数据最终形态一定是带有参数的url链接，凡事可以转化成url的都可以作为数据源。传统扫描器依赖用户手工录入域名或者IP，爬虫以域名或者IP作为起点去爬url。总结下可以作为数据源的包括以下几种：

WEB服务器日志

网络流量 WAF／IDS等安全设备日志 域名／IP

其中基于网络流量来做扫描器数据源，也叫做PVS（Passive Vulnerability Scanner），最早由Tenable网络安全公司开发，后来成为整个网络安全行业的通用功能。由于商标权原因，有些网络安全厂商称之为实时漏洞分析。大量数据源的接入，可以比较好的解决API服务以及较复杂动态页面爬虫难以爬取的问题。但是这个技术是双刃剑，尤其是在API服务的环境下。生产实践中，非常多的API服务甚至缺乏基础的鉴权和限速保护，直接使用流量中提取的URL进行扫描，无形之中做了攻击重发，非常容易造成不可预期的结果，比较典型的就是误删／误查／误改业务数据。