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

創(chuàng)新互聯(lián)建站是一家專業(yè)提供武夷山企業(yè)網(wǎng)站建設(shè),專注與做網(wǎng)站、成都做網(wǎng)站、H5技術(shù)、小程序制作等業(yè)務(wù)。10年已為武夷山眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計(jì)公司優(yōu)惠進(jìn)行中。

1. 前言

sql注入如何檢測(cè)的？

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

1) 報(bào)錯(cuò)注入檢測(cè)。

2) 別做bool的報(bào)錯(cuò)注入，誤報(bào)比較高。

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

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

2. 簡(jiǎn)單分析sqlmap的time-based注入

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

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

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

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

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

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

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

3. 深入分析一下源碼

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

sqlmap/lib/controller/checks.py:

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

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

sqlmap/xml/payloads/time_blind.xml:

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

4. 閉合

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

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

5. 判斷是否延時(shí)

5.1 方法一

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

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

當(dāng)注入時(shí)間為sleep(0)，將當(dāng)前時(shí)間減去ori_time，作為sleep_time。如果sleep_time大于2，說(shuō)明延時(shí)有誤報(bào)。

5.2 方法二

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

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

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

最后判斷當(dāng)前這次請(qǐng)求的消耗時(shí)間是不是大于lowerStdLimit，大于說(shuō)明延時(shí)發(fā)生，小于說(shuō)明沒(méi)有(另外，當(dāng)lowerStdLimit小于0.5秒時(shí)候，lowerStdLimit取0.5秒)。

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

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