首页 > 代码库 > [漏洞检测]Proxpy Web Scan设计与实现(未完待续)
[漏洞检测]Proxpy Web Scan设计与实现(未完待续)
Proxpy Web Scan设计与实现
1、简介:
Proxpy Web Scan是基于开源的python漏洞扫描框架wapiti改造的web漏洞扫描器,其主要解决以下几个问题而生:
(1)、当前互联网业务处于快速发展阶段,由于小版本更新迭代快,很难做到发布前必定经过安全测试。此外,安全小组面临安全人员不足和人工安全测试重复性工作过高的问题,
(2)、当前业界的漏洞扫描器更多的是基于简单的爬虫加扫描引擎的模式,可定制化幅度小,易用性和可扩展性都不是太好,如果要嵌入到发布流程则更加困难。
因此需要打造一套能够测试基础安全问题的,可定制化程度高的,最终能够满足业务发展需求的自动化漏洞扫描器,
2、架构:
2.1、架构图:
2.1.1、wapiti架构:
Wapiti原生架构主要由2部分组成:爬虫引擎和漏洞扫描引擎。其有一般的漏洞扫描器的优点,但是缺点也很明显,比如,不支持登录录制(但支持cookie)、不支持多线程导致速度慢、只支持单一目标站点的扫描和漏洞覆盖率低等。架构图如下:
2.1.2、Proxpy Web Scan架构:
Proxy Web Scan主要又3大部分组成:http代理、爬虫和漏洞扫描引擎。经过改造后和原生wapiti相比,其主要优点如下:
(1)、更加透明化和傻瓜化。一般情况下,使用人员只需设置HTTP代理即可。如果把使用人员推广到研发部和测试部,那么基本上能保证新版本上线都必定经过基础安全扫描。
(2)、漏洞覆盖面广。依靠客户端流量导向到代理服务器,可以捕抓在页面上没有入口的URL,这也是爬虫模块的短板之处。此外,爬虫模块还移植了御剑后台扫描系统,进一步挖出隐蔽的极难被发现的URL,而这些URL往往具有更高的价值。
(3)、支持的漏洞检测类型更多。原生wapiti只支持9种常见漏洞扫描,改造后可支持15种类型的漏洞扫描。
(4)、速度大幅度提升。Proxy Web Scan支持多线程的爬虫和扫描,并且支持多个不同的站点同时扫描,效率和速度均大幅度提升。
(5)、可定制化程度高。实际使用中往往会有一些特殊需求或疑难问题,依靠传统特别是闭源的扫描器很难去实施解决。
架构图如下:
2.2、工作原理:
(1)、 将Proxy Web Scan代理服务器设置为客户端(比如浏览器和移动APP等)的http代理,当浏览目标站点时,客户端的http数据流将定向到代理服务器(Proxy)。
(2)、代理服务器将来自客户端的http数据流以及将来自目标站点的响应数据分别转发给双方,以此保证客户端能够和目标站点保持正常通信。
(3)、代理服务器将来自客户端的http数据流写入数据库,并作为原始数据流。
(4)、爬虫模块从数据库读取原始数据流并对目标站点进行爬取,原始数据和爬取获得的新数据最终均存在全局队列中。
(5)、扫描引擎从全局队列获取数据进行扫描,并最终输出报告。
2.3、效果对比:
| 多线程 | http(s)代理 | 强制浏览 | 检测类型 | 误报率 | 数据库 |
Wapiti | 不支持 | 不支持 | 不支持 | 6种 | 一般 | 不支持 |
Proxy Web Scan | 支持 | 支持 | 支持 | 15种 | 更低 | 支持 |
3、模块设计:
3.1、http(s)代理:
3.1.1、简介:
http(s)代理模块用于捕获所有客户端到服务器之间的web流量并存放在数据库中,目前暂时只支持基于http/https的GET和POST方法。
3.1.2、架构图:
3.1.3、工作原理:
代理服务器实则作为客户端和目标站点之间的“中间人”,在双方之间均建立了独立的连接,负责接收和转发双方之间的数据,但对双方来说,代理服务器是透明的,双方始终会认为在跟真实的对方在通信,这种建立双连接的方式,可以让代理服务器获取到双方之间的明文通信数据(包括https),为后续的爬虫和扫描打下了坚实基础,工作流程如下:
(1)、客户端向目标站点发起请求,由于设置了http(s)代理,请求将被定向到代理服务器。
(2)、客户端和代理服务器端口建立连接,并发送http(s)请求数据。
(3)、 代理服务器对数据进行解析后,向目标站点发起和建立连接,并将来自客户端的http(s)请求数据转发给目标站点。
(4)、代理服务器接收来自目标站点的http(s)响应,并对其进行解析,如果满足条件,该http(s)请求将被记录进数据库。
(5)、代理服务器将目标站点的http(s)响应转发给客户端,同时断开连接。
注意:当使用浏览器访问一个https站点时,代理服务器会使用一个与目标站点不匹配的假证书去和浏览器通信,由于浏览器本身检查证书的有效性,当发现证书验证不通过时会弹出警告提示,对于IE,此时只要点击“继续浏览此网站”即可,其它浏览器有类似选择。
3.1.4、流程图:
3.1.5、模块文件详述:
(1)、proxpy.py
代理服务器主程序入口,同时主要负责解析外来参数,比如监听端口和地址等。
(2)、core.py
代理服务器的核心程序,实现了处理来自客户端的请求的解析以及转发到目标站点和来自目标站点响应的解析以及转发到客户端的功能,此外,还实现了request在数据库的存储。
(3)、http.py
实现了用于描述http request和http response的类,即把它们封装成对象,并实现了相关方法,比如,获取request的参数和序列化response等。
(4)、https.py
实现了和https连接相关的方法,比如ssl握手。
(5)、proxpy.pem
用于和客户端建立SSL连接的公私钥证书
3.2、爬虫模块
3.2.1、简介:
网络爬虫(Web crawler),是一种“自动化浏览网络”的程序,或者说是一种网络机器人。它们被广泛用于互联网搜索引擎或其他类似网站,以获取或更新这些网站的内容和检索方式。它们可以自动采集所有其能够访问到的页面内容,以便程序做下一步的处理。
3.2.2、架构图:
3.2.3、工作原理:
爬虫必须是从至少一个初始URL开始工作的,并从初始URL的返回内容进行分析和提取更多的URL,经过分析以后,对于有效的URL将被存放在等待队列里面等待调度爬取,以此循环直至结束。在本设计中,初始URL来自于http(s)代理模块捕抓到的用户请求,这些请求已经在http(s)代理阶段存入数据库,可直接由爬虫模块读取使用。
3.2.4、流程图:
3.2.4.1、总体流程图:
3.2.4.2、强制浏览(BruteFc)流程图:
一般情况下,目标站点的可访问的URL都可以通过网页进行分析和提取,但有时候有些URL是不存在于网页内的,只能靠手动输入该URL进行访问,典型的比如:管理员web登录后台等。强制浏览是一种发现这种无法通过爬虫探测的URL的手段,即通过将常用的URI存储到一个字典里面,并循环将字典里面的URI拼接到目标站点,最终形成可访问的URL,当访问该URL时,如果服务器返回200,表明该URL存在,随后可URL可作为爬虫进行爬取的依据,流程图如下:
3.2.5、关键技术解析:
3.2.5.1、动/静态页面解析(on-going):
通过基于webkit的模块处理动态页面,通过htmlparser处理静态页面。
3.2.5.2、URL去重:
爬虫模块在爬取URL的过程中一般至少存在2个队列,等待爬取队列,已爬取队列,等待爬取队列用于存放未被爬取过的准备被调度模块调度爬取的URL,已爬取队列用于记录所有已爬取过的URL。URL去重是指爬虫从响应的页面中提取URL后,需要检查该URL是否已在这两个队列中,避免反复的爬取相同的页面导致无线循环。
hash表是解决这一问题的最简单的方法,即计算当前提取的URL的哈希值,并检查该值是否存在待爬取或已爬取队列的哈希表中,因为hash表查询的时间复杂度是O(1),而且在hash表足够大的情况下,hash冲突的概率就变得很小,因此URL是否重复的判断准确性就非常高。
3.2.5.3、URL去相似(on-going):
3.2.6、模块文件详述:
(1)、Crawler.py
爬虫模块主程序,主要包括3个大类:Crawler、CrawlBackstage和linkParser。Crawler类实现了分析器、调度器和下载器模块。CrawlBackstage实现了强制浏览模块功能,linkParser用于实现对页面的解析和URL提取。
(2)、HTTP.py
对http request和response进行封装,用于实现http请求的发送和响应的接收处理。
3.3、漏洞扫描引擎
3.3.1、简介:
每一种漏洞都有其特定的探测特征值(payload),通过手动对目标输入指定的特征值,存在漏洞和不存在漏洞的系统的响应是存在差异的,但是因为环境的差异,同一种漏洞在不同的环境下特征值也会存在差异,由于环境的复杂性,这就导致了一种漏洞可能会存在很多种变异的特征值,如果通过人为手动的输入这些特征值去探测某种类型的漏洞是非常耗时的。
漏洞扫描引擎是一组用于探测目标系统安全缺陷的程序。它的主要特点是:高效,快速和准确。即替代了大量的人工工作量,将和业务没有相关性或相关性低的安全缺陷通过自动化的方式挖掘出来,既能满足业务快速迭代开发上线的需求,也能节省人力成本和投入。
3.3.2、架构图:
3.3.3、工作原理:
漏洞扫描引擎的工作原理是把大量的漏洞特征值存储在数据库或文件中,并按漏洞类型进行分类,当需要探测某种类型的漏洞时,将该漏洞对应的特征值依次提取出来并和正常的http请求结合组成漏洞探测请求(exploit),同时根据其响应的特征值判定漏洞是否存在。
3.3.4、流程图:
3.3.5、关键技术解析:
由于漏洞挖掘技术和利用手段在不断更新,因此,将漏洞检测机制设计为可扩展是非常必要的,它使得当发现的新型漏洞时,能够让用户迅速扩展扫描器的功能以适应新的需求和变化。本扫描器使用可扩展扫描插件的设计,即用户要新增新型漏洞扫描与检测,只需要在指定目录下增加新的脚本插件、payload和漏洞描述即可。
3.3.6、模块文件详述:
(1)、vulscanner.py
主程序文件,负责漏洞检测模块、配置、队列和报表等的初始化工作,并启动多漏洞扫描引擎。
(2)、Attack目录
漏洞检测引擎的主目录,其中attack.py是其它所有漏洞检测插件的父类,通过继承该父类获得基础能力。
(3)、util.py
常用功能模块均定义在此文件。
(4)、DBUtils目录
数据库线程池模块。
(5)、config目录
配置文件所在目录。配置文件以xml的格式存在。
(6)、report目录:
报表模块,目前只支持http、xml和txt格式的报表。
(7)、report_template
报表模板文件,最终的报表将会在该模板上修改和输出。
3.4、多线程同步队列
3.5、数据库设计和线程池
3.6、报表模块
3.7、SocketServer模块
4、问题汇总:
(1)、代理服务器转发request时,得到的response数据是乱码。
问题分析:
客户端在发起http请求时,一般http头部都会带上Accept-Encoding: gzip, deflate的header,这意味着目标站点会响应一个经过压缩的response,导致代理服务器收到乱码数据。
解决方案:
代理服务器转发request到目标站点前,将http request的Accept-Encoding header移除。
(2)、代理服务器收到目标站点的response数据,但转发到浏览器时,浏览器没有响应。
问题分析:
个人认为可能和问题1有一定关系,但目前问题分析不确切。
解决方案:
将目标站点response头部中的Transfer-Encoding :chunked header删除即可。
[漏洞检测]Proxpy Web Scan设计与实现(未完待续)