如何實現(xiàn)sqlmap time-based inject的分析

這篇文章將為大家詳細講解有關(guān)sqlmap time-based inject 分析，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

1. 前言

sql注入如何檢測的？

我的回答是：在甲方做安全，sql注入檢測還是比較好做的。

1) 報錯注入檢測。

2) 別做bool的報錯注入，誤報比較高。

3) 做基于time-based的時間注入，聯(lián)系運維做上慢日志db記錄，監(jiān)控sleep，benchmark的關(guān)鍵字監(jiān)控，可以在sleep的時間小數(shù)點上加上掃描任務(wù)的id號，方便定位。(p.s. 這種方法能找到99%的sql注入了)

因此，在做基于time-based的時間注入時，我把時間誤差限制的非?？量?。但是，@chengable在乙方做安全相關(guān)工作，基于time-based的時間注入一般是做不了的。據(jù)了解，他主要是先過濾存在注入點的情況，再加上sqlmapapi.py檢測。早之前我也用sqlmap做過檢測，遇到的問題就是誤報多、掃描時間久，然后嘗試了sqlmapapi.py，問題還是掃描時間過久，而且它不支持json格式的注入(詳情)。但是，sqlmap的時間注入還是比較準的，如果不想用sqlmapapi.py怎么辦？這里就把sqlmap的time-based注入的邏輯搬出來。

2. 簡單分析sqlmap的time-based注入

吐槽一下：sqlmap的代碼不規(guī)范、難看、量又大。之前有大佬推薦我閱讀sqlmap源碼，學習一波，現(xiàn)在想想還好我放棄的早。

所以，偷懶不想看源碼加上--technique=T -v 3 就先看看sqlmap檢測payload。

貌似偷懶還找到了一些門道，從截圖中可以看到：

首先，sqlmap塞入了sleep的注入payload：

先是塞入了 sleep(5)，發(fā)現(xiàn)執(zhí)行了之后；又塞入sleep(0)，最后又塞入sleep(5)。

然后猜測一下，大概的檢查思路就是先sleep(5)，秒延時成功的話，再sleep(0)。如果沒有發(fā)現(xiàn)延時現(xiàn)象，繼續(xù)sleep(5)，此時如果再次延時成功，就出現(xiàn)認為可能有注入的提醒：

最后，很巧妙的是，sqlmap為了防止出現(xiàn)誤報使用了if 的判斷條件來排除誤報，從上圖可以看到sqlmap分別讓等式成立測試兩次，又讓等式不成立測試兩次，根據(jù)秒延時情況來判斷誤報。

3. 深入分析一下源碼

回歸源碼看看：根據(jù)前面的一些關(guān)鍵字，我們直接到代碼里面去看看。比如搜索之前出現(xiàn)*appears to be* 看到第一步的代碼：

sqlmap/lib/controller/checks.py:

這里發(fā)現(xiàn)，和前面猜測的八九不離十。

再找一下payload在哪里，特別是if條件的payload，還是用關(guān)鍵字查詢，發(fā)現(xiàn)在這里：

sqlmap/xml/payloads/time_blind.xml:

可以看到每個if條件的payload都在vector這個字段中。

4. 閉合

閉合注入點前面的字符是能否注入的關(guān)鍵。

觀察到 tools/sqlmap/xml/boundaries.xml，所以，我們還需要參考這里面的多種閉合情況：

5. 判斷是否延時

5.1 方法一

參考之前awvs的注入，我想到一個比較容易理解的檢測方法。取6次無注入payload正常測試的消耗時間，計算平均值為原生請求時間(ori_time)。

當注入時間為sleep(5)，將當前時間減去ori_time，作為sleep_time。如果sleep_time小于4，認為延時沒有發(fā)生。（這里考慮到ori_time 受到網(wǎng)絡(luò)影響導致變大，所以把閥值調(diào)到了四秒）

當注入時間為sleep(0)，將當前時間減去ori_time，作為sleep_time。如果sleep_time大于2，說明延時有誤報。

5.2 方法二

再看一下sqlmap的代碼，人家用了一個我搞不懂的數(shù)學問題(詳情)

跟進：Request.queryPage --->wasLastResponseDelayed 就可以看到邏輯為：取30次的無注入payload正常測試的消耗時間，將他們放到kb.responseTimes中。計算30次的標準差為deviation，根據(jù)deviation計算出一個最慢的響應(yīng)時間為lowerStdLimit：

它的值為30次的平均值加上TIME_STDEV_COEFF*標準差(deviation)，至于TIME_STDEV_COEFF，設(shè)置為7可以使得判斷的準確度在99.9999999997440%。

最后判斷當前這次請求的消耗時間是不是大于lowerStdLimit，大于說明延時發(fā)生，小于說明沒有(另外，當lowerStdLimit小于0.5秒時候，lowerStdLimit取0.5秒)。

感性告訴我該選方法一，理性告訴我該選方法二。我還是選擇方法二，測了一下這個注入點（詳情）。很穩(wěn)定的掃描出了注入漏洞。

關(guān)于sqlmap time-based inject 分析就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。