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