Web漏扫测试心得

由于实习工作的原因，需要采购一批web漏扫设备，需要进行测试。于是最近接触了好多厂商和他们的设备下面简单说一下自己的感想。

靶场

由于手头靶场的匮乏，暂时只在办公室的服务器中利用docker搭建了DVWA和WebGoat两个靶场。除此之外接受厂商自带的靶场，如果哪个厂商的靶场比较好就会选用这个靶场并用其他厂商的设备扫一下这个靶场来看看效果，最后还是通过控制变量的方法争取在同一个靶场的结果中对比多家厂商来看。

DVWA算是比较（非常）常见的靶场了，我原本以为厂商听到测试DVWA会感觉“窃喜”因为这个靶场实在是太低端了，可以说刚入门web安全的人才使用这个靶场练手。但事实好像和我想象的有些出入，大部分厂商在DVWA上的测试结果和我估计的有些出入。有些甚至感觉根本没有测过DVWA（按理说应该在研发阶段就经常用来测试的靶场，没想到都到了客户处测试，前来测试的测试人员居然没听说过DVWA）。

WebGoat这个靶场甚至绝大部分厂商不能进行测试，因为WebGoat这个靶场是使用Spring框架开发的，前后端完全分离的技术，并且控制前端页面显示的参数是通过url锚点后的数据来控制的。这让很多传统爬虫的设备完全无法爬取WebGoat的页面。具体我会在下面说明。

扫描方式

大部分厂商的设备都有爬虫扫描的功能，即是基于传统爬虫来爬取网站进而进行扫描。但对于目前的一些新技术比如前后端分离的网站，或前端是使用js渲染出来的网站，这种基于http协议的爬虫并不能很好或者说并不能爬取。未解决这种问题，不同厂商想出了不同的办法，有模拟真实浏览器执行js的，也有通过代理然后人工浏览网站进而实现被动扫描。

在扫描方式这里，A厂商的这台仅支持爬虫式的扫描，不能进行代理式或人工介入交互式的扫描，所以只能扫描传统的web网站如php，asp，jsp等，对于新的如VUE渲染的网站表现的比较无力。

B厂商的设备可以同时支持爬虫式的扫描和被动信息搜集扫描，无论什么扫描方式，整体流程分为信息搜集和漏洞探测两步骤。主要区别在于信息搜集步骤，爬虫式扫描可同时支持模拟浏览器的爬虫，可以解析js脚本并能响应其变化。除此之外被动代理就是将设备配置成代理之后，通过人工浏览网站，设备会对这过程中的所有请求进行分析也能实现大部分的前后端分离式网站的爬取。

C厂商的设备只支持被动代理式扫描，无法通过爬虫来扫描。虽说麻烦一些，但由于是人工操作的信息搜集环境，定位漏洞更加精确。个人认为比较适用于刚开始进行到测试流程的项目，可将设备作为测试人员的浏览器代理，在测试的过程中记录访问数据包，并进行漏洞检测。但由于没有爬虫扫描的功能，并不适用于日常的周期性扫描。

D厂商的设备和A差不多，仅有爬虫的能力。但值得一提的是，在扫描过程中，假如遇到有身份认证的站点（需要登录），D设备会通过爆破的方式进行身份认证但也只能通过爆破的方式，无法通过配置cookie，或登录录制或被动扫描等方式解决身份认证问题。

完整性

完整性是指对设备功能的需求，比如比较明显的代理，身份认证扫描，爬虫参数配置，字典修改等等，原本以为这些基本的需求对于厂商而言都是具备的，但在实际测试的时候发现并不是。

A厂商倒是满足大部分的功能需求，但无法修改字典。

B厂商几乎完全满足功能的需求，而且还提供了多种身份认证的模式，如cookie，表单，协议认证。

C厂商也满足了几乎全部的功能需求。

D厂商就比较查了，由于D厂商的这款设备不只是web漏扫一个功能，除此之外还有上网行为检测等功能，更像是一种监测类设备。而且在开发的时候，本着“尽力从简”的理念，在漏扫方面的功能就有些欠缺，只有设置任务最基本的参数，代理，身份认证扫描，爬虫参数配置，字典修改等均不支持。但只是前端页面没有表现出接口而已，在产品本身设计上，以上配置都可在底层系统中修改配置文件达成（麻烦了而已）。

稳定性

稳定性是我在本次测试过程中提出的概念，因为我发现一些厂商的设备如B厂商会出现多次扫描结果不一致的问题。最开始以为是我们服务器网络的问题，怀疑是因为延迟等造成结果判断有误以至于多次扫描报告结果不一致，但后来经过多目标的测试发现结果不一致的特性是普遍的，因为我不是尝试的研发人员，所以我也不好说明造成这个现象的原因是什么。而且出现这个现象的厂商并不在少数。

所以稳定性指的是由于扫描器自身在执行扫描任务时由于插件本身的问题或插件间互相影响的问题或由于网络问题（也可理解为设备本身对网络需求比较大）造成的多次扫描不一致现象。如出现这种现象，在测试我能想到的解决方式是进行多次测试，将测试结果取并集。但也仅仅在时间充裕的情况下才行。

对于稳定性，A厂商我感觉是表现最好的了，不只是每次扫描时间都很接近，而且扫描结果一直，对服务器影响也非常小，即使是我一个实习生也能感觉到在这背后A厂商一定对优化算法等做了很大的研究，下了很大的功夫。

B厂商（我刚刚也提到过）由于一些网络原因，当然研发也解释了也和sql注入插件有关的原因（会影响其他插件）会造成多次扫描结果不一致的问题。

C厂商由于完全是被动扫描，没有出现类似的问题，但有时会造成页面超时而得不到结果的问题。

D厂商设备上的插件间会造成一些轻微的影响，而导致多次扫描结果存在小幅度偏差。

性能及安全性

性能不单单是一个扫描任务的耗时、耗资源，更关键的是对服务器的影响。比如当服务器存在高危漏洞的时候，扫描任务会不会造成服务器的文件，数据等的篡改或删除，以及扫描时会不会造成服务器宕机等。

A厂商的设备在扫描时没有发现对服务器有攻击行为（就像刚才说的，对服务器很友好）也不会出现宕机等情况。

B厂商的设备更加安全，研发介绍中说，为了保证客户的安全，放弃了一些漏洞的发现能力而去掉了一些比较危险的payload，比如sql注入中的or。所以客观来说，是比A厂商更加安全的。

C厂商的设备表现了比较强的攻击性，在测试中对我们测试环境中的业务网站造成了数据删除和篡改的影响，而且也经常会将靶场扫挂。

D厂商在测试中并没有表现出很严重的攻击性，只是在并发数较高的情况下，服务器也会产生延迟。

漏洞发现能力

在关注一款漏扫设备的时候好像首要关注的就是它的漏洞发现能力，在web漏扫的漏洞发现能力中，我们差不多将其归为两类，开发类漏洞和产品类漏洞，解释一下就是开发类漏洞即那些sql注入，xss等的在开发中由于开发人员不遵守安全开发规范或疏忽造成的漏洞；而产品类漏洞则是由于项目中使用的外部框架、中间件或插件等组件自带的漏洞。开发漏洞往往特征不明显，根据出现的位置的不同而拥不同的特征，发现也比较困难，而产品类漏洞则通常具有自己的CVE或CWE编号，特征也比较固定比较明显，对于机器而言更好发现。

综上所述，不难推断出，在产品漏洞的检测方面，各厂商的能力应该是不相上下的，因为只要漏洞库涵盖对应的CVE漏洞，而客户的项目中使用了对应版本的含有漏洞的产品，不出意外就都能成功检测（因为漏洞指纹都是一样的）。而对于开发漏洞，可以说不同的开发人员习惯不同，漏洞的指纹在不同的编码风格中也不尽相同，所以真正考验的是各设备对于开发类漏洞的发现能力。在本次测试中，针对开发类漏洞的分类，我是按照OWASP标准进行分类，具体分类列请移步我上一篇博客（看目录就行了）。

由于靶场的问题，以上这些漏洞并不能完整的覆盖，但主要危害与主要关注的漏洞基本能够覆盖（如sql注入，xss等主流关注漏洞）。而且除此之外，每个厂商自己也带了靶场前来测试，交叉测试（选出比较好的厂商靶场，各家都扫一下以对比）之下，虽不能的处具有普遍性的结果，但也可以得出各厂商间相对的结果。

在没有具有普遍性的结果的前提下，仅通过目前的对比测试，A厂商的设备的漏洞发现能力良好，在通用靶场的测试中可以说名列前茅，而且还能再和B厂商提供的靶场扫描上和B厂商打平。反观其他厂商对A厂商提供的靶场表现都不如A。

B厂商发小漏洞的能力一般，在通用靶场和友商靶场上的表现都不如A靶场。

C厂商发现漏洞的能力较好，但也有“只能被动扫描”的原因存在，因为人工会把具有漏洞的页面定位，而设备只是单纯的发现而已，在这种情况下，达到了和A不相上下的能力。

D厂商的设备发现漏洞的能力很强，稍稍强于A，但由于身份认证功能，代理，修改字典，批量扫描等功能的缺失，造成有些站点出现“根本没办法扫” 的情况，所以即使发现漏洞的能力很强，但其他因素还是有些制约。

总结

A

A厂商的设备应该是最稳定的了，在多次测试中结果都能保持一致，而且对服务器几乎没有伤害。可见优化做的非常到位。而且就发现漏洞的能力也是名列前茅，能在各种测试环境中表现出比较优秀的能力。但唯一美中不足的就是不支持被动扫描和扫描前后端分离的这种站点。

B

B厂商的设备应该是最安全的了，而且对我们需求的功能也几乎全部包括，但可能表现的不是很稳定，发现漏洞的能力也不是很突出。

C

C厂商的设备由于完全被动的扫描模式还是在一些特殊的地方非常有用武之地，而且发现漏洞的能力很强，但表现的攻击性也比较强。

D

D厂商的设备发现漏洞的能力很突出，而且还能扫描产品型的漏洞（同样能力很突出），但由于一些功能的缺失（比较不是主打的web漏扫）可能并不是非常的实用，但除了漏扫这台设备还兼具了一些其他比较重要的功能，所以应用场景来说，可能只用web漏扫功能有点屈才。