白帽子挖洞—SQL注入篇

0x00介紹

SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意的）SQL命令注入到後台資料庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的資料庫，而不是按照設計者意圖去執行SQL語句。

對於初學者而言，找漏洞最好是基於白盒審計進行，所謂白盒審計可以簡單地理解為就是看著代碼找漏洞，當然了，在web方面的代碼審計可沒想像的那麼輕鬆，不會像C語言中很經典的溢出，先定義一個buffer，然後用一個gets()函數直接獲取內容，這麼簡單的溢出，泥萌也太小瞧程序媛/猿了。在web方面的代碼審計，感謝偉大的社會主義社會，我國大部分的網站都是php建的（畫外音：php是世界是最好的語言，哈哈），所以大多數情況下我們都是審計php代碼，php函數又那麼多，相互之間互相調用，使得代碼審計不容易，當然了，也不難，只要掌握了技巧，結合經驗，就能找出漏洞所在。在0x04部分小表弟會給出一些自己的經驗。

在正式挖洞前，我們先看看DVWA給出的四種級別的SQL注入的源代碼。

0x01基於dvwa的代碼審計

DVWA 的代碼分為四種安全級別：Low，Medium，High，Impossible。初學者可以通過比較四種級別的代碼，接觸到入門級別的代碼審計的內容。

DVWA使用界面

SQL注入（SQL Injection）

在左下角的DVWA Security可以調節難度係數，即low,medium,high,impossible選中後點擊submit提交即可。

點擊左下角view source可以看到源代碼，方便進行代碼審計

我們可以看到四種級別的代碼分別如下所示：

代碼：

低級（low）

分析：

關鍵語句：

$id = $_REQUEST[ "id" ]; // Check database $query = "SELECT first_name, last_name FROM users WHERE user_id = "$id";";

可以看到：

Low級別的代碼對來自客戶端的參數id沒有進行任何的檢查與過濾，存在明顯的SQL注入。

中級（medium）

分析：

關鍵代碼：

$id = mysql_real_escape_string( $id ); // Check database $query = "SELECT first_name, last_name FROMusers WHERE user_id = $id;";

可以看到：

Medium級別的代碼利用mysql_real_escape_string函數對特殊符號x00,
,
,,』,」,x1a進行轉義，在一定程度上控制了用戶的輸入

高級（high）

分析：

關鍵語句：

$query = "SELECT first_name, last_name FROM users WHERE user_id = $idLIMIT 1

可以看到：

代碼希望通過LIMIT 1來控制使得只輸出一個查詢結果

不可能(Impossible）

分析：

關鍵代碼：

$data = $db->prepare( "SELECT first_name, last_name FROM users WHERE user_id = (:id) LIMIT 1;" ); $data->bindParam( ":id", $id, PDO::PARAM_INT );

可以看到：

代碼中限制返回的查詢結果數量為一時，才會輸出，防止了大量數據的泄露，同時採用了PDO技術，隔離了代碼與數據，使得用戶輸入的數據不再被當作代碼執行，採用這種方案，杜絕了SQL注入漏洞的發生

0x02挖掘漏洞

註：

1.接下來的過程中會大量用到sqlmap，部分站點的漏洞將直接以sqlmap的形式給出。所以建議小夥伴先去熟悉下sqlmap。

2. 以下提交的漏洞均已被廠家修復，小夥伴們就不要想搞事情了

3.本文展現的漏洞在測試前已獲授權，請小夥伴們勿非法測試

先來枚有web頁面的漏洞：

存在漏洞的頁面

掃目錄時發現該url下存在某事件型漏洞

採用某位大神的中轉腳本：

通過sqlmap神器成功挖到漏洞

拿到的資料庫

Sqlmap測試時截圖

總結：第一枚漏洞主要是採用某事件型漏洞結合sqlmap挖到的，難度相當於DVWA中的Medium級別

什麼？沒有數據看著不過癮？你這是要搞事情啊大兄弟！好吧，再來一枚數據量大的

第二枚漏洞：

測試時沒有截web的圖，只有sqlmap，將就著看吧，看看

存在漏洞的站點

Sqlmap掃一發

加個—tables繼續

就拿上張圖的mallbuilder來開刀吧

繼續—current-db

紅色打碼的部分是手機號或真實姓名或郵箱號，過於敏感就打碼了，可以看到圖中下面password就是密碼編碼加密後的字元串

拿到用戶名和密碼後我們可以登陸後台

紅色打碼部分為收貨人姓名及手機號，有一條還包括收貨地址

紅色打碼部分為手機號

可以看到後台所有的功能我們都是可以使用的，就不繼續了

總結：通過簡單的sqlmap命令指定特定的表、資料庫來「脫褲」，拿到後台登陸帳號密碼，進而進行進一步的操作。此站點的代碼強度相當於DVWA中的Medium級別.

0x03資源推薦

代碼審計方面可以使用法師尹毅（Seay）的源代碼審計系統

DVWA方面的實際操作可以登陸合天網安實驗室進行練習，連接如下：

http://www.hetianlab.com/cour.do?w=1&c=C172.19.104.182015061009315500001

SQL注入時的神器SQLMAP在合天網安實驗室也有相應的課程，連接如下：

http://www.hetianlab.com/cour.do?w=1&c=C172.19.104.182015011916013600001

抓包改包看參數的神器burpsuite在合天網安實驗也有相應課程，連接如下：

http://www.hetianlab.com/cour.do?w=1&c=C172.19.104.182014112610353900001

0x04經驗心得

SQL注入漏洞挖掘的總體的思路：

1. SQL注入漏洞的判斷，即尋找注入點

2. 判斷後台資料庫類型

3. 確定XP_CMDSHELL可執行情況；若當前連接數據的帳號具有SA許可權(這是SQL系統中的最高許可權)，且master.dbo.xp_cmdshell擴展存儲過程(調用此存儲過程可以直接使用操作系統的shell)能夠正確執行，則整個計算機可以通過幾種方法完全控制，也就完成了整個注入過程，否則繼續：

1. 發現WEB虛擬目錄

2. 上傳ASP木馬；

3. 得到管理員許可權

了解了思路，在實際挖洞的過程中，常常會碰到需要繞過的情形，針對這種情況，表弟給大家提供了常用的繞過方法

一、引號繞過

會使用到引號的地方是在於最後的where子句中。如下面的一條sql語句，這條語句就是一個簡單的用來查選得到users表中所有欄位的一條語句。

select column_name from information_schema.tables where

這個時候如果引號被過濾了，那麼上面的where子句就無法使用了。那麼遇到這樣的問題就要使用十六進位來處理這個問題了。

select column_name from information_schema.tables

二、逗號繞過

在使用盲注的時候，需要使用到substr() ,mid() ,limit。這些子句方法都需要使用到逗號。對於substr()和mid()這兩個方法可以使用from to的方式來解決。

select substr(database(0 from 1 for 1);

select mid(database(0 from 1 for 1);

對於limit可以使用offset來繞過

select * from news limit 0,1

# 等價於下面這條SQL語句

select * from news limit 1 offset 0

三、比較符(<,>)繞過

同樣是在使用盲注的時候，在使用二分查找的時候需要使用到比較操作符來進行查找。如果無法使用比較操作符，那麼就需要使用到greatest來進行繞過了。

最常見的一個盲注的sql語句。

select * from users where id=1 and

此時如果比較操作符被過濾，上面的盲注語句則無法使用,那麼就可以使用greatest來代替比較操作符了。greatest(n1,n2,n3,等)函數返回輸入參數(n1,n2,n3,等)的最大值

那麼上面的這條sql語句可以使用greatest變為如下的子句:

select * from users where id=1 and greatest(ascii(substr(database(),0,1)),64)=64

0x05防護措施

1、解決SQL注入漏洞的關鍵是對所有來自用戶輸入的數據進行嚴格檢查、對資料庫配置使用最小許可權原則所有的查詢語句都使用資料庫提供的參數化查詢介面，參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。避免網站顯示SQL錯誤信息，比如類型錯誤、欄位不匹配等，防止攻擊者利用這些錯誤信息進行一些判斷。

2、對進入資料庫的特殊字元（""<>&*;等）進行轉義處理，或編碼轉換。嚴格限制網站用戶的資料庫的操作許可權，給此用戶提供僅僅能夠滿足其工作的許可權，從而最大限度的減少注入攻擊對資料庫的危害。

3、數據長度應該嚴格規定，能在一定程度上防止比較長的SQL注入語句無法正確執行。確認每種數據的類型，比如數字型的數據就必須是數字，資料庫中的存儲欄位必須對應為int型。 網站每個數據層的編碼統一，建議全部使用UTF-8編碼，上下層編碼不一致有可能導致一些過濾模型被繞過

以上僅為個人觀點，歡迎小夥伴們提出意見討論。

本文為合天原創獎勵文章，轉載請聯繫微信公眾號「合天智匯」！未經允許，禁止轉載！