sql注入如何偵測的?
我的回答是:在甲方做安全,sql注入偵測還是比較好做的。
1) 報錯注入偵測。
2) 別做bool的報錯注入,誤報比較高。
3) 做基於time-based的時間注入,聯繫運維做上慢日誌db記錄,監控sleep,benchmark的關鍵字監控,可以在sleep的時間小數點上加上掃描任務的id號,方便定位。 (p.s. 這種方法能找到99%的sql注入了)
因此,在做基於time-based的時間注入時,我把時間誤差限制的非常苛刻。但是,@chengable在乙方做安全相關工作,基於time-based的時間注入一般是做不了的。據了解,他主要是先過濾存在註入點的情況,再加上sqlmapapi.py檢測。早之前我也用sqlmap做過檢測,遇到的問題就是誤報多、掃描時間久,然後嘗試了sqlmapapi.py,問題還是掃描時間過久,而且它不支援json格式的注入(詳情)。但是,sqlmap的時間注入還是比較準的,如果不想用sqlmapapi.py怎麼辦?這裡就把sqlmap的time-based注入的邏輯搬出來。
吐槽一下:sqlmap的程式碼不規範、難看、量又大。之前有大佬推薦我看sqlmap源碼,學習一波,現在想想還好我放棄的早。
所以,偷懶不想看原始碼加上--technique=T -v 3 就先看看sqlmap偵測payload。
#似乎偷懶也找到了一些門道,從截圖可以看到:
首先,sqlmap塞入了sleep的注入payload:
先是塞入了sleep(5),發現執行了之後;又塞入sleep(0),最後又塞入sleep(5)。
然後猜測一下,大概的檢查思路就是先sleep(5),秒延時成功的話,再sleep(0)。如果沒有發現延時現象,繼續sleep(5),此時若再次延時成功,就出現認為可能有註入的提醒:
appears to be* 看到第一步的程式碼:
##跟進:Request. queryPage --->wasLastResponseDelayed 就可以看到邏輯為:取30次的無注入payload正常測試的消耗時間,將他們放到kb.responseTimes中。計算30次的標準差為deviation,根據deviation計算出一個最慢的回應時間為lowerStdLimit:
它的值為30次的平均值加上TIME_STDEV_COEFF*標準差(deviation),至於TIME_STDEV_COEFF,設定為7可以使得判斷的準確度在99.9999999997440%。
最後判斷目前這次要求的消耗時間是不是大於lowerStdLimit,大於說明延遲發生,小於說明沒有(另外,當lowerStdLimit小於0.5秒時候,lowerStdLimit取0.5秒)。
感性告訴我該選方法一,理性告訴我該選方法二。我還是選方法二,測了一下這個注入點(詳情)。很穩定的掃描出了注入漏洞。
以上是如何實作sqlmap time-based inject的分析的詳細內容。更多資訊請關注PHP中文網其他相關文章!