SQLMAP 例項COOKBOOK

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

0x00 概述

---

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

SQL注射原理傳送門/papers/?id=59

SQLMAP使用者手冊傳送門/tips/?id=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提示的圖，所以目前找不到是哪一個了）