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