SQLMAP 實例COOKBOOK

lxj616 · 2014/03/30 10:52

提醒：本文章中的全部例子均已經過烏雲平臺通知廠商，並按照流程已經公開（未公開的會有標識而且隱藏信息，請等待公開後自行查看），請在閱讀文章的同時不要對文中所列漏洞重複測試，謝謝

0x00 概述

---

本文章面向 已經理解SQL注射基本原理、已經配置好並瞭解SQLMAP基本命令、但缺少實踐的入門者。在文章中總結了本身在烏雲上發佈的近三十個SQL注射漏洞，對於SQLMAP在不一樣場景下的應用給出了 實例總結，對於SQLMAP的基本介紹、安裝配置、命令手冊請你們自行百度。

SQL注射原理傳送門drops.wooyun.org/papers/59

SQLMAP用戶手冊傳送門drops.wooyun.org/tips/143

0x01 從HelloWorld開始思考

---

WooYun: WanCMS 多處SQL注射（源碼詳析+實站演示）

形如：

C:\Users\Administrator>sqlmap.py -u "http://?a=b" –tables
複製代碼

WooYun: 吉林市人力資源和社會保障局 Oracle injection

[email protected]:~# sqlmap -u "www.jljl.lss.gov.cn/ybcx.asp" --data="yblb=%D2%BD%C1%C6%B1%A3%CF%D5&ybxm=123&ybsfzh=123" --tables
複製代碼

相信你們都已經滾瓜爛熟，爛熟於心。

例子a)

SQLMAP首先測試a（惟一的參數），檢測結果以下

Type: boolean-based blind（heuristic test 基本測試就能發現）

Type: UNION query      （在至少發現其餘一種注射存在時會擴大測試範圍，原始是1-10，而這裏測試到了20，這是自動擴展的）

Type: AND/OR time-based blind （正常等級測試便可發現）
複製代碼

效率很高，檢測很準確，跑表成功，一切都很好，這是一個完美的HelloWorld

例子b)

SQLMAP首先測試yblb，沒有發現注射，而後檢測ybxm，結果以下:

Error-based（直接會告訴你是oracle，而後根據提示測試會很順利）
Union query（正常測試就能測試出來）
And or time based（正常測試就能測試出來）
複製代碼

咱們發現，在測試yblb的時候SQLMAP浪費了咱們好多時間（這個漏洞我是手工fuzz的，我知道是ybxm打單引號報的錯，若是是掃描器掃描也一樣知道漏洞出在ybxm） 那麼，何須浪費時間呢？

改進方案：指定測試參數 –p ybxm

改良的例子：

WooYun: 今題網某分站SQL注射漏洞

C:\Users\Administrator>sqlmap.py -u "http://club.jinti.com/operation/setmoodinfo.aspx?bodyid=52164&channel=a&classid=0&mood=mood1rand=0.10818770481273532" -p channel –tables
複製代碼

避免了測試沒必要要的參數浪費時間

這也是本文章的目的，讓新手們少走彎路，快速順利地完成檢測任務。

0x02 須要登錄後訪問的頁面

---

有時注射點的位置須要登陸（手動測試時發現、掃描器配置了登錄sequence掃描）

解決方案：使用—cookie選項（cookie是burpsuite或者tamperdata手工抓的）

WooYun: CSCMS V3.5 最新版 SQL注射（官方站演示+源碼詳析）

形如：

C:\Users\Administrator>sqlmap.py -u "http://?a=b" -p a --dbms=mysql --cookie="cookie" –tables
複製代碼

0x03 老是提示302 redirect（重定向）

---

明明掃描器掃出來的，手工測試也過了，可一到sqlmap就是302。

多是要重定向到error頁面，這種狀況有時屬於正常情況（部分boolean-based payload會致使），可是老是這樣，多是referer中有限制，或者cookie要登錄，再或者是agent須要換

帶上referer（從掃描器請求中找）

解決方案：使用—referrer 選項

例子：

WooYun: 聯衆世界SQL注射漏洞可致數據庫信息泄露

形如：

C:\Users\Administrator>sqlmap.py -u "http:// " --data="? " -p ? --referer="http:// " --tables
複製代碼

cookie見0x03

改變user-agent

解決方案：使用random-agent 選項

例子：

WooYun: 攜程網主站+分站多個SQL注入漏洞打包

形如：

C:\Users\Administrator>sqlmap.py -u "http:// " --referer="a" --level 3 --random-agent --dbms="microsoft sql server" --techniqu
e T --tables
複製代碼

固然，若是你知道它要求你用某一種agent，你也應當用user-agent選項本身指定所需的agent（好比說ie6）

0x04 僞靜態中的注射

---

不少網站會使用僞靜態，參數形式通過變化後比較隱蔽，這給工具自動化注射帶來了難度

先說一個悲慘的反面案例：

WooYun: phpweb建站程序可致使大量政府網站受到安全影響

在這個例子裏，我爲了跑表不惜本身寫了一個php的轉發請求的腳本，結果勞民傷財。

諷刺的是，我竟然用的是SQLMAP。

正確的解決方案：

使用「*」符號來自定義注射位置（米字鍵、星號、小鍵盤像雪花那個鍵）
複製代碼

正確的案例：

WooYun: 鐵友網某站SQL注射可致全部數據庫信息泄露

形如：

C:\Users\Administrator>sqlmap.py -u "http://*" –tables
複製代碼

會提示發現「*」號，是否處理，選擇y

0x05 注射referer

---

通常狀況下，指定level 3以上纔會檢查referer

實例：

WooYun: 攜程旅行網主站 SQL注射可致大量數據庫信息泄露

形如：

C:\Users\Administrator>sqlmap.py -u "" --level 3 --referer="a" --random-agent --tables
複製代碼

我其實曾經悲慘地又用轉發請求的方式發過一個referer漏洞

Referer中也是可使用「*」來自訂的

0x06 手工構造注射語句自動化

---

有時候咱們須要對注射語句手工調整，好比閉合各類括號單引號，好比補全後面的語句（常見於insert中的注射），以及在僞靜態中的調整等等

解決方案：手工構造後，使用「」號指定注射點（好像也能夠指定prefix和surfix來實現，不過我本身習慣於用「」號）

以後會提示：「在url中發現疑似手動測試遺留的詞法，建議……」，選擇繼續測試

例子：

WooYun: 久遊網SQL注射 可致數據庫信息所有泄漏（跑表演示）

形如：

C:\Users\Administrator>sqlmap.py -u "http:// " --data=" &?=a' or 1=1* --&…… " -p ? –tables
複製代碼

這個我後來想一想構造的不妥，不過跑表正常，不深究了

0x07 提示unexploitable point detected

---

測試時報告injectable，可是又提示不能注射，多是服務端作了某些防禦措施（好比過濾了少許的關鍵字）可是明顯過濾作的不嚴格

或者是掃描器掃描出了盲注問題，可是SQLMAP檢測不出injectable而咱們又不想放棄

那麼，可使用—level 選項增長測試項（因爲大量的測試會大大減緩測試速度，因此通常狀況下不要開這個選項）

例子：

WooYun: 螞蜂窩主站SQL注射可致數據庫信息泄露 
複製代碼

徹底公開

C:\Users\Administrator>sqlmap.py -u "www.mafengwo.cn/shop/mgr_item.php?act=add&item_name=lgkcaleg&item_price=1&shop_id=100597" -p item_name --tables --dbms=mysql --technique T --level 5
複製代碼

0x08 指定dbms

---

在上一節中增長level會使檢測速度難以忍受，這時就要進一步的縮短測試流程，其中很重要的一項就是指定dbms（這樣能夠跳過其餘無關dbms的檢測程式，和error-based發現dbms類型後提示你是否略過其餘dbms的檢測同理）

解決方案：

使用--dbms選項
複製代碼

例子：仍是上面0x08那個例子

0x09 指定方法盲注測試

進一步加快測試速度？使用--technique T指定盲注吧（固然若是不是盲注的你能夠換其餘參數）能夠跳過大量的union測試（level高時會擴展到1-100，這是很漫長的等待）

例子：仍是上面0x08那個例子

0x0a 過濾了空格

---

有些時候網站會「不當心」過濾掉各類字符，能夠用tamper來解決（對付某些waf時也有成效）

例子：

WooYun: phpweb建站程序可致使大量政府網站受到安全影響

把空格過濾掉了（應該還有全部不可見字符）

--tamper=」space2comment.py」

理論是用/**/代替空格

同時若是過濾了其餘字符，也可查閱手冊可用的tamper選項

0x0b 過濾了逗號

---

查找了大量資料後，決定手注……

例子：

WooYun: iSiteCMS發佈安全補丁後仍然有幾處注射漏洞（源碼詳析+實站演示）

裏面還轉義了「>」和「<」，不過能夠經過Rlike繞過，可是逗號始終解決不了

各位有沒有帶着SQLMAP成功繞過逗號的經歷？交流一下？

0x0c 從新測試時異常

---

有時在測試的過程當中，須要作少量調整從新再來一遍，可是重來時發現了異常

WooYun: 今題網某分站SQL注射漏洞

注意截圖中的提示：

Sqlmap identified the following injection points with a total of 0 HTTP(S) requests
複製代碼

一看以爲奇怪，沒有發請求怎麼知道的注射點？

實際上是以前運行過測試，因爲某些緣由從新又來了一遍，可是重來的這一遍徹底使用了以前保存的檢測結果

雖然這個例子中一切都正常，但我親自碰到過由於這個緣由形成沒法從新調整測試的狀況，解決方式是刪除掉output中的對應記錄文件（建議用手冊中的安全方法，儘管我一直習慣直接刪文件夾……）

0x0d 取回數據異常

---

有時發現跑出的數據都是毫無心義的字符

解決方案：

a）SQLMAP會提示你加—hex或者—no-cast，有時會有幫助
b）若是你用的是time-based注射，建議增長延時—time-sec等參數，即便你的網速比較好，可是服務器可能碰見各類奇怪環境
c）增長level 值得一試
複製代碼

因爲烏雲上都是成功跑表的結果，暫無實例

0x0e 從burpproxy到sqlmap的捷徑

---

有時從proxy上截到的包想要放進sqlmap中，須要複製不少項（cookie、referer、post）等，解決方案：使用 -l 選項 把burpproxy的記錄直接導入sqlmap

因爲這種帶着文件的漏洞難以提交烏雲平臺（難以復現除非給文件），因此我提交的漏洞都轉成了一行命令形式，所以沒有實例

並且有些時候咱們須要先手工構造一下（好比說json裏面的注射須要自定義注射點）

這種狀況下若是盲目整包丟進SQLMAP，會致使漏報

實例：

WooYun: 國家獸藥基礎信息查詢系統 SQL注射

0x0f 暴力猜表

---

在遇到access的站的時候，老是要猜想表名

在\txt下保存着common-tables.txt，是猜想時使用的表名（SQLMAP在猜想時會根據頁面信息自動組裝前綴什麼的）

個人經驗是：若是你知道大概會存在什麼表，那麼本身去構造common-tables.txt吧，好比掃描時出現的soucecode-exposure（源代碼泄露）、頁面錯誤信息、或者你的靈感

Txt下的其餘文件正如其名，同理猜想其餘數據

實例：

WooYun: 高郵市某網站修補不當 仍然存在SQL注射

因爲GOOGLE到以前的某些漏洞數據，知道部分表名後更改common-tables猜想

0x10 老是unable to connect to the target url

---

第一種狀況多是time-out設置的過小，可是這個可能性已經不大了，能夠試試增長--time-out嘗試

解決方案：增長--time-out，可能最好清掉output遺留文件（見0x13）

例子：

WooYun: 國家獸藥基礎信息查詢系統 SQL注射

裏面的unable to connect to the target url提示徹底是由響應過慢致使的，不過因爲沒有嚴重影響跑表的過程，因此直接忽視掉了

再有可能就是WAF直接把請求攔截掉了，所以得不到響應

有些waf比較友善，過濾後會提示「參數不合法」，可是也有些waf則直接把請求攔下來無提示致使應答超時，這樣在測試時會消耗大量的時間等待響應

解決方案：減小time-out進行檢測，在跑數據時改回time-out

因爲烏雲上只給出跑表結果，所以暫無實例

0x11 提示possible integer casting detected

---

意思是檢測到了相似intval的過濾，常見於形如http://xxx.x?a=1在SQLMAP檢測dynamic和basic test 時頁面毫無弱點，好比手工測試時a=1 和 a=2 顯示不一樣頁面，可是a=1’ 或者a=1sdf 或者 a=1 and 1=2 都返回原來的a=1的響應，所以SQLMAP推測可能服務器端有intval的過濾。

若是你是在手工測試，建議到這裏能夠中止了，節省時間。

若是你是在掃描器掃描的盲注，那麼到這裏堅定無視警告繼續下去。

實例：

忘記是哪一個漏洞有這麼回事了，可是當時掃描器報告有盲注，因此無視警告繼續後成功跑表，如今想一想可能服務器端是用了intval後再次使用了沒有intval的參數（日誌記錄 insert），因此跑出來的表都是日誌數據庫（當時沒截intval提示的圖，因此目前找不到是哪個了）