前言:
如今咱们对“html解析器扫描器”大约比较重视,你们都需要了解一些“html解析器扫描器”的相关文章。那么小编同时在网摘上汇集了一些对于“html解析器扫描器””的相关内容,希望咱们能喜欢,你们快快来学习一下吧!对web网站、应用等系统进行扫描,从而提早发现更多的安全漏洞,是保护系统不可缺少的手段。一般的web安全扫描大多使用web扫描器,扫描器利用爬虫技术,对目标系统进行资源遍历并检测代码等来发现漏洞,一方面可以减少人工检测的工作量,另一方面误报和漏报也比较多。原因之一是爬虫无法检测一些隐藏较深的系统资源(比如:深层的URL)。这篇文章,笔者主要想和大家探讨减少误报漏报的一个思路。
设计
开始探讨之前,我们先了解一下web漏洞扫描的一般过程和原理,大致分2种:
web扫描器:
利用爬虫获取目标系统的所有URL,再尝试模拟访问这些URL获取更多的URL,如此循环,直到所有已知的URL被获取到,或者利用已知URL列表对目标系统的URL进行穷举,从而获取有效的URL资源。把获取的URL去重后,利用已知漏洞的检测代码对这些URL进行检测,以判断目标系统是否存在漏洞。
人工检测:
通过设置代理(如:burp)来截获所有目标系统的访问请求,然后依据经验对可能存在问题的请求修改参数,或者添加检测代码并重放(如:burp中的repeat功能),从而判断目标系统是否存在漏洞。
web扫描器可以极大的减少人工检测的工作量,但由于爬虫的局限性容易导致误报和漏报;而人工检测可以很好的保证准确性,但依赖于检测人员的经验和精力,尤其是大型系统,很难在有限的时间内完成检测,同样会造成误报和漏报。那么,假如能有效地利用扫描器的处理速度又兼顾人工的精准度的话,是不是就可以很好地解决误报和漏报了呢?我们不禁思考,如果有办法可以获取到所有的真实请求(包括:请求头,cookie,url,请求参数等等)并配合扫描器的检测代码是不是可以更有效的对系统进行漏洞检测呢?
假设有这样一个系统,可以在用户与系统之前获取到所有的请求,并分发给扫描器进行检测,这样只要请求来自于真实的应用场景或者系统的功能,那么就可以最大程度地收集到所有真实有效的资源。故可以设计该系统包含如下的子模块:
客户端:用户访问系统的载体,如:浏览器,手机APP
代理:用于获取来自于客户端的所有请求,如:Burp,Load Balancer
解析器:负责将代理获取的请求数据按照规定格式解析并插入至请求数据库中
请求数据库:用于存放代理获取的所有请求数据以及解析器和扫描器的配置信息
扫描器:具有漏洞检测功能的扫描器,如:自行编写的定制扫描器(hackUtils),SQLMAP,Burp Scanner,WVS,OWASP ZAP等
应用系统:目标应用系统,如:Web系统,APP
基本架构如下:
从上图中,代理可以将所有对目标系统的访问请求获取并存储在一个中心数据库中,然后将这些真实的请求分发给不同的扫描器进行检测。每个子模块都只负责自己的功能,相互之间并不干扰,且仅通过中心数据库关联起来,因此可以灵活扩展多个代理和扫描器。例如:
对于测试人员,只需要在本地设置好代理(如:burp),然后在浏览器或者APP中正常地访问或者测试应用的每一个页面和功能,接下来的漏洞检测工作就完全交给了扫描器去做,这极大地节约了时间和避免了大量重复的手工检测的工作。
对于企业系统,可以将代理设置在应用前端(如:load balancer),这样所有的请求将会被自动镜像在扫描数据库,并自动分发给多个扫描引擎进行检测,无需手工干预即可发现很多隐藏很深的漏洞。
实践
为验证这种思路,笔者设计了一个Demo。
该系统在浏览器或者手机的wifi中配置好了burp作为代理,浏览应用的每一个页面和功能时,代理将会自动地收集所有请求数据,包括各种请求头、cookie、请求方法、请求数据等,然后通过解析器的解析并存储于中央数据库,最后再分发于多个扫描引擎对请求的所有可控输入点进行repeat检测。效果如下:
以下是我封装的一个python的requests库,它支持发送自定义的cookie,headers的get/post的请求,并可以是使用PhantomJS引擎去解析和渲染GET请求响应的页面中的javascript,css等,可以非常方便的应用于反爬虫和DOM型XSS的检测。Code:
思考
从漏洞检测的角度来说,经过笔者的测试(以DVWA和WebGoat为例)检测效果还是非常明显和有效的。其实这种类似的设计,很早之前就已经有人做了,那么很多人要问了为什么你还要在重复造个轮子呢?其实原因有以下几点:
1.系统耦合性较强,不利于进行扩展和改造
2.在HTTPS的流量捕获上支持的不是很好
3.没有做到对HTTP请求中所有的可控输入点进行检测,例如,仅仅检测GET/POST数据,而对cookie,user-agent, referer等缺乏检测
4.缺乏对于DOM的渲染和解析,容易造成对于基于DOM的漏洞的漏报,比如:DOM型的XSS等
5.不具备分布式部署的能力,无法有效利用分布式处理的优点来提高检测效率
6.不具备真正的意义上的repeat检测能力,换句话说不能完全模拟用户的请求
当然,上述的设计也存在一些待解决的问题,比如:若将代理部署至应用前端镜像所有请求,再分发至扫描引擎检测,如何防止真实用户数据泄漏和篡改?可能的解决方案是设置例外,对于敏感字段或者请求进行例外处理。
标签: #html解析器扫描器