本文轉自網際網路

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：
> www.how2playlife.com

本文是微信公眾號【Java技術江湖】的《重新學習MySQL資料庫》其中一篇，本文部分內容來源於網路，為了把本文主題講得清晰透徹，也整合了很多我認為不錯的技術部落格內容，引用其中了一些比較好的部落格文章，如有侵權，請聯絡作者。

該系列博文會告訴你如何從入門到進階，從sql基本的使用方法，從MySQL執行引擎再到索引、事務等知識，一步步地學習MySQL相關技術的實現原理，更好地瞭解如何基於這些知識來最佳化sql，減少SQL執行時間，透過執行計劃對SQL效能進行分析，再到MySQL的主從複製、主備部署等內容，以便讓你更完整地瞭解整個MySQL方面的技術體系，形成自己的知識框架。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

本文轉自網際網路

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：
> www.how2playlife.com

本文是微信公眾號【Java技術江湖】的《重新學習MySQL資料庫》其中一篇，本文部分內容來源於網路，為了把本文主題講得清晰透徹，也整合了很多我認為不錯的技術部落格內容，引用其中了一些比較好的部落格文章，如有侵權，請聯絡作者。

該系列博文會告訴你如何從入門到進階，從sql基本的使用方法，從MySQL執行引擎再到索引、事務等知識，一步步地學習MySQL相關技術的實現原理，更好地瞭解如何基於這些知識來最佳化sql，減少SQL執行時間，透過執行計劃對SQL效能進行分析，再到MySQL的主從複製、主備部署等內容，以便讓你更完整地瞭解整個MySQL方面的技術體系，形成自己的知識框架。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

## 前言

### 靶場準備

首先我們來準備一個web介面服務，該服務可以提供管理員的資訊查詢，這裡我們採用springboot + jersey 來構建web服務框架，資料庫則採用最常用的mysql。下面，我們來準備測試環境，首先建立一張使用者表jwtk_admin，SQL如下：

然後插入預設的管理員：

這樣我們就有了兩位系統內建管理員了，管理員密碼採用MD5進行Hash，當然這是一個很簡單的為了作為研究靶場的表，所以沒有很全的欄位。

接下來，我們建立 spring boot + jersey 構建的RESTFul web服務，這裡我們提供了一個透過管理員使用者名稱查詢管理員具體資訊的介面，如下：

### SQL隱碼攻擊測試

首先我們以開發者正向思維向web服務傳送管理員查詢請求，這裡我們用PostMan工具傳送一個GET請求

不出我們和開發者所料，Web介面返回了我們想要的結果，使用者名稱為admin的管理員資訊。OK，現在開發任務完成，Git Push，Jira任務點為待測試，那麼這樣的介面就真的沒有問題了嗎？現在我們傳送這樣一條GET請求：

傳送該請求後，我們發現PostMan沒有接收到返回結果，而Web服務後臺卻開始拋 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 ‘‘xxxx’’’ at line 1

原因是在我們查詢的 xxxx’ 處sql語句語法不正確導致。這裡我們先不討論SQL語法問題，我們繼續實驗，再次構造一條GET查詢請求:

此時，我們可以驚訝的發現，查詢介面非但沒有報錯，反而將我們資料庫jwti_admin表中的所有管理員資訊都查詢出來了：

這是什麼鬼，難道管理員表中還有 name=xxxx’or’a’='a 的使用者？這就是 SQL Injection。

## 注入原理分析

在介面中接受了一個String型別的name引數，並且透過字串拼接的方式構建了查詢語句。在正常情況下，使用者會傳入合法的name進行查詢，但是駭客卻會傳入精心構造的引數，只要引數透過字串拼接後依然是一句合法的SQL查詢，此時SQL隱碼攻擊就發生了。正如我們上文輸入的name=xxxx’or’a’='a與我們介面中的查詢語句進行拼接後構成如下SQL語句：

當介面執行此句SQL後，系統後臺也就相當於拱手送給駭客了，駭客一看到管理員密碼這個hash，都不用去cmd5查了，直接就用123456密碼去登入你的後臺系統了。Why？因為123456的md5雜湊太常見了，別笑，這就是很多中小網站的現實，弱口令橫行，不見棺材不落淚！

好了，現在我們應該明白了，SQL Injection原因就是由於傳入的引數與系統的SQL拼接成了合法的SQL而導致的，而其本質還是將使用者輸入的資料當做了程式碼執行。在系統中只要有一個SQL隱碼攻擊點被駭客發現，那麼駭客基本上可以執行任意想執行的SQL語句了，例如新增一個管理員，查詢所有表，甚至“脫褲” 等等，當然本文不是講解SQL隱碼攻擊技巧的文章，這裡我們只探討SQL隱碼攻擊發生的原因與防範方法。

## JDBC的預處理

在上文的介面中，DAO使用了比較基礎的JDBC的方式進行資料庫操作，直接使JDBC構建DAO在比較老的系統中還是很常見的，但這並不意味著使用JDBC就一定不安全，如果我將傳入的引數 xxxx’or’a’='a 整體作為引數進行name查詢，那就不會產生SQL隱碼攻擊。在JDBC中，提供了 PreparedStatement （預處理執行語句）的方式，可以對SQL語句進行查詢引數化，使用預處理後的程式碼如下：

同樣，我們使用上文的注入方式注入 ，此時我們發現，SQL隱碼攻擊沒能成功。現在，我們來列印一下被被預處理後的SQL，看看有什麼變化：

看到了嗎?所有的 ’ 都被 ’ 轉義掉了,從而可以確保SQL的查詢引數就是引數，不會被惡意執行，從而防止了SQL隱碼攻擊。

## Mybatis下注入防範

MyBatis 是支援定製化 SQL、儲存過程以及高階對映的優秀的持久層框架， 其幾乎避免了所有的 JDBC 程式碼和手動設定引數以及獲取結果集。同時，MyBatis 可以對配置和原生Map使用簡單的 XML 或註解，將介面和 Java 的 POJOs(Plain Old Java Objects,普通的 Java物件)對映成資料庫中的記錄，因此mybatis現在在市場中採用率也非常高。這裡我們定義如下一個mapper，來實現透過使用者名稱查詢管理員的介面：

同樣提供Web訪問介面：

接下來，我們嘗試SQL隱碼攻擊name欄位，可以發現注入並沒有成功，透過列印mybatis的Log可以看到mybatis框架對引數進行了預處理處理，從而防止了注入：

那是否只要使用了mybatis就一定可以避免SQL隱碼攻擊的危險？我們把mapper做如下修改，將引數#{name}修改為${name}，並使用name=‘xxxx’ or ‘a’=‘a’ 作為GET請求的引數，可以發現SQL隱碼攻擊還是發生了：

那這是為什麼，mybatis ${}與#{}的差別在哪裡？

原來在mybatis中如果以形式宣告為SQL傳遞引數，mybatis將不會進行引數預處理，會直接動態拼接SQL語句，此時就會存在被注入的風險，所以在使用mybatis作為持久框架時應儘量避免採用

形式宣告為SQL傳遞引數，mybatis將不會進行引數預處理，會直接動態拼接SQL語句，此時就會存在被注入的風險，所以在使用mybatis作為持久框架時應儘量避免採用形式宣告為SQL傳遞引數。

mybatis將不會進行引數預處理，會直接動態拼接SQL語句，此時就會存在被注入的風險，所以在使用mybatis作為持久框架時應儘量避免採用{}的形式進行引數傳遞，如果無法避免（有些SQL如like、in、order by等，程式設計師可能依舊會選擇${}的方式傳參），那就需要對傳入引數自行進行轉義過濾。

## JPA注入防範

JPA是Sun公司用來整合ORM技術，實現天下歸一的ORM標準而定義的Java Persistence API（java持久層API），JPA只是一套介面，目前引入JPA的專案都會採用Hibernate作為其具體實現，隨著無配置Spring Boot框架的流行，JPA越來越具有作為持久化首選的技術，因為其能讓程式設計師寫更少的程式碼，就能完成現有的功能。

例如強大的JpaRepository，常規的SQL查詢只需按照命名規則定義介面，便可以不寫SQL（JPQL/SQL）就可以實現資料的查詢操作，從SQL隱碼攻擊防範的角度來說，這種將安全責任拋給框架遠比依靠程式設計師自身控制來的保險。因此如果專案使用JPA作為資料訪問層，基本上可以很大程度的消除SQL隱碼攻擊的風險。

但是話不能說的太死，在我見過的一個Spring Boot專案中，雖然採用了JPA作為持久框架，但是有一位老程式設計師不熟悉於使用JPQL來構建查詢介面，依舊使用字串拼接的方式來實現業務，而為專案安全埋下了隱患。

安全需要一絲不苟，安全是100 - 1 = 0的業務，即使你防禦了99%的攻擊，那還不算勝利，只要有一次被入侵了，那就有可能給公司帶來很嚴重的後果。

關於JPA的SQL隱碼攻擊，我們就不詳細討論了，因為框架下的注入漏洞屬於框架漏洞範疇（如CVE-2016-6652），程式設計師只要遵循JPA的開發規範，就無需擔心注入問題，框架都為你做好幕後工作了。

## SQL隱碼攻擊的其他防範辦法

很多公司都會存在老系統中有大量SQL隱碼攻擊風險程式碼的問題，但是由於其已穩定支援公司業務很久，不宜採用大面積程式碼更新的方式來消除注入隱患，所以需要考慮其採用他方式來防範SQL隱碼攻擊。除了在在SQL執行方式上防範SQL隱碼攻擊，很多時候還可以透過架構上，或者透過其他過濾方式來達到防止SQL隱碼攻擊的效果。

一切輸入都是不安全的：對於介面的呼叫引數，要進行格式匹配，例如admin的透過name查詢的介面，與之匹配的Path應該使用正則匹配（因為使用者名稱中不應該存在特殊字元），從而確保傳入引數是程式控制範圍之內的引數，即只接受已知的良好輸入值，拒絕不良輸入。注意：驗證引數應將它與輸出編碼技術結合使用。

利用分層設計來避免危險：前端儘量靜態化，儘量少的暴露可以訪問到DAO層的介面到公網環境中，如果現有專案，很難修改存在注入的程式碼，可以考慮在web服務之前增加WAF進行流量過濾，當然程式碼上就不給hacker留有攻擊的漏洞才最好的方案。也可以在擁有nginx的架構下，採用OpenRestry做流量過濾，將一些特殊字元進行轉義處理。

儘量使用預編譯SQL語句：由於動態SQL語句是引發SQL隱碼攻擊的根源。應使用預編譯語句來組裝SQL查詢。

規範化：將輸入安裝規定編碼解碼後再進行輸入引數過濾和輸出編碼處理；拒絕一切非規範格式的編碼。

## 小結

其實隨著ORM技術的發展，Java web開發在大趨勢上已經越來越遠離SQL隱碼攻擊的問題了，而有著Entity Framework框架支援的ASP.NET MVC從來都是高冷範。在現在網際網路中，使用PHP和Python構建的web應用是目前SQL隱碼攻擊的重災區。本文雖然是從JAVA的角度來研究SQL隱碼攻擊的問題，但原理上同樣適用於其他開發語言，希望讀者可以透過此文，觸類旁通。

珍愛資料，遠離拼接，有輸入的地方就會有江湖…

重新學習MySQL資料庫11：以Java的視角來聊聊SQL隱碼攻擊

相關文章