BurpSuite插件编写——辅助漏洞测试
BurpSuite插件基本编写原理
BurpSuite插件的编写流程并不复杂,主要在实现官方的接口,进而实现对应的功能;首先必须实现IBurpExtender接口,并重写registerExtenderCallbacks方法,比如最简单的burp插件代码
其中IBurpExtenderCallbacks是BurpSuite通过回调函数与的形式将一系列操作的回调函数传给插件,比如要使用registerMenuItem注册菜单。那么就在registerExtenderCallbacks函数中通过调用callbacks.registerMenuItem实现。
除了该接口外,BurpSuite还提供了各种功能的接口,比如要新增一个IntruderPayload生成器,则通过实现IIntruderPayloadGenerator接口中的getNextPayload、hasMorePayloads等方法,并通过callbacks.registerIntruderPayloadGeneratorFactory,传入实现的IIntruderPayloadGenerator的类对象即可实现相关代码可以参考https://www.cnblogs.com/LyShark/p/9102250.html除此之外BurpSuite其他接口功能,都可以参考官方文档来实现https://portswigger.net/burp/extender/api/index.html
辅助测试功能
我要实现的功能就是辅助测试,总结我们每次进行漏洞发现的流程,常规的测试流程基本是一致的,比如针对SQL注入漏洞,会使用单引号、双引号、布尔、时间盲注测试payload进行测试,那么我要做的功能有两个:1.自动添加这些测试payload 2.自动使用这些payload进行发包探测
并且我不需要对所有参数进行fuzz,这样就成为一个扫描器了,而且现在参数解析及其麻烦,因此上述两个功能是在BurpSuite中通过光标指定位置进行。
针对插入payload的代码,即通过实现IContextMenuFactory接口中的createMenuItems方法实现,这里不再赘述,下文主要阐述一下SQL注入扫描逻辑是如何编码的。
SQL注入扫描逻辑
扫描器编写的两个难点
- 参数解析
- 结果识别
由于开发的灵活性,前后端参数传递可以有很多种方式进行,比如在get参数值中传json格式数据,这种复杂的参数传递方式目前传统的扫描器很难进行有效的处理,只能在已有的参数解析规则上加上定制的解析规则,没有比较有效的解决方案。
结果识别上,扫描的流程包括payload插入、发包、获取响应包、判断是否存在漏洞,前面三个流程都是相对简单,但是判断是否存在漏洞就存在诸多的情况,比如针对xss漏洞,我们知道输入点和输出点可能并不在同一页面,再比如现在前后端分离的开发模型,前端页面通过接口的方式进行数据传递,save操作接口仅返回处理结果,而并不是跳转到特定页面,因此很难根据接口返回结果进行识别,这一问题的解决方法为使用headless等无头浏览器进行动态扫描。
本插件目前实现了SQL注入的三种扫描方式,相关方法在本人以前写的被动扫描器扫描原理上实施,主要原理参考了SQLMap
报错注入
报错注入的扫描比较简单,直接将单引号、双引号、反斜杠等会造成闭合错误的特殊符号放在一起,并根据页面报错内容进行判断
布尔盲注
比尔盲注的扫描难点在于如何识别真假样本下的页面的响应特征,插件采用页面相似度判断方法
计算原始请求/脏数据请求、原始请求/真条件、真条件/假条件三组请求的响应页面的相似度
并根据相似度差别
diff_raw_true.ratio() > diff_raw_rubbish.ratio() and diff_true_false.ratio() <= diff_raw_rubbish.ratio()
判断是否存在布尔盲注
时间盲注
时间盲注参考了SQLMAP的时间计算标准计算方式即30次请求均值 + 7倍请求时间均方差
为了减少发送不必要的请求,我们在布尔盲注未扫出漏洞的情况下,进行时间盲注扫描,因此可以将布尔盲注中请求时间进行记录,应用到时间盲注的时间延迟基准计算中,
在布尔盲注未扫出漏洞的情况下,会发送22个请求,记录这22个请求的时间,并计算时间延迟计算标准,然后使用时间盲注payload进行请求,当时间延迟大于该时间即可认为
延迟payload有效,再发送一次原始请求,如果未发生延迟,即判断为时间盲注
效果演示
本插件具有良好的扩展性,如果需要新增相关payload以及重写扫描逻辑,均可在代码基础上进行修改
代码仓库地址: https://github.com/donot-wong/EasyBurpVuln