提醒：本文章中的所有例子均已通過烏雲平臺通知廠商，並按照流程已經公開（未公開的會有標識並且隱藏信息，請等待公開後自行查看），請在閱讀文章的同時不要對文中所列漏洞重複測試，謝謝
0x00 概述
本文章面向 已經理解SQL注射基本原理、已經配置好並瞭解SQLMAP基本命令、但缺乏實踐的入門者。在文章中總結了自己在烏雲上發佈的近三十個SQL注射漏洞，對於SQLMAP在不同場景下的應用給出了 實例總結，對於SQLMAP的基本介紹、安裝配置、命令手冊請大家自行百度。
SQL注射原理傳送門 http://drops.wooyun.org/papers/59
SQLMAP用戶手冊傳送門 http://drops.wooyun.org/tips/143
0x01 從HelloWorld開始思考
WooYun: WanCMS 多處SQL注射（源碼詳析+實站演示）
形如：
C:\Users\Administrator>sqlmap.py -u "http://?a=b" –tables
WooYun: 吉林市人力資源和社會保障局 Oracle injection
root@kali:~# 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
改良的例子：
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 選項
例子：
形如：
C:\Users\Administrator>sqlmap.py -u "http:// " --data="? " -p ? --referer="http:// " --tables
cookie見0x03
改變user-agent
解決方案：使用random-agent 選項
例子：
形如：
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。
正確的解決方案：
使用“*”符號來自定義注射位置（米字鍵、星號、小鍵盤像雪花那個鍵）
正確的案例：
形如：
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 重新測試時異常
有時在測試的過程中，需要做少許調整重新再來一遍，但是重來時發現了異常
注意截圖中的提示：
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，會導致漏報
實例：
0x0f 暴力猜表
在遇到access的站的時候，總是要猜測表名
在\txt下保存着common-tables.txt，是猜測時使用的表名（SQLMAP在猜測時會根據頁面信息自動組裝前綴什麼的）
我的經驗是：如果你知道大概會存在什麼表，那麼自己去構造common-tables.txt吧，比如掃描時出現的soucecode-exposure（源代碼泄露）、頁面錯誤信息、或者你的靈感
Txt下的其他文件正如其名，同理猜測其他數據
實例：
由於GOOGLE到之前的某些漏洞數據，知道部分表名後更改common-tables猜測
0x10 總是unable to connect to the target url
第一種情況可能是time-out設置的太小，但是這個可能性已經不大了，可以試試增加--time-out嘗試
解決方案：增加--time-out，可能最好清掉output遺留文件（見0x13）
例子：
裏面的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提示的圖，所以目前找不到是哪一個了）
