SQL注入和Mybatis預編譯防止SQL注入

什麼是SQL注入？？

所謂SQL注入，就是經過把SQL命令插入到Web表單提交或頁面請求url的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來講，它是利用現有應用程序，將（惡意）的SQL命令注入到後臺數據庫引擎執行的能力，它能夠經過在Web表單中輸入（惡意）SQL語句獲得一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。

實戰舉例 有個登錄框以下：

能夠看到除了帳號密碼以外，還有一個公司名的輸入框，根據輸入框的形式不難推出SQL的寫法以下：

SELECT * From table_name WHERE name=‘XX’ and password=‘YY’ and corporate=‘ZZ’
複製代碼

怎麼作呢，？

由於沒有校驗，所以，咱們帳號密碼，都不填寫，直接在最後，添加 or 1=1 –

看看與上面SQL組合，成了以下：

SELECT * From table_name WHERE name=’’ and password=’’ and corporate=’’ or 1=1-’
複製代碼

從代碼能夠看出，前一半單引號被閉合，後一半單引號被 「–」給註釋掉，中間多了一個永遠成立的條件「1=1」，這就形成任何字符都能成功登陸的結果。

重要提醒

不要覺得在輸入框作個檢查就夠了，不要忘記了，咱們web提交表單，是能夠模擬url直接訪問過去，繞開前段檢查。所以，必須是後端，或是數據來檢查纔能有效防止。

（1）檢查用戶輸入的合法性；

（2）將用戶的登陸名、密碼等數據加密保存。

（3）預處理SQL。

（4）使用存儲過程實現查詢，雖然不推薦，但也是一個方法。

---

MySQL預處理是怎麼防止的呢？

MyBatis框架做爲一款半自動化的持久層框架，其SQL語句都要咱們本身手動編寫，這個時候固然須要防止SQL注入。其實，MyBatis的SQL是一個具備「輸入+輸出」的功能，相似於函數的結構，以下：

<select id="getBlogById" resultType="Blog" parameterType=」int」>

         SELECT id,title,author,content

         FROM blog

WHERE id=#{id}

</select>
複製代碼

這裏，parameterType表示了輸入的參數類型，resultType表示了輸出的參數類型。迴應上文，若是咱們想防止SQL注入，理所固然地要在輸入參數上下功夫。上面代碼中黃色高亮即輸入參數在SQL中拼接的部分，傳入參數後，打印出執行的SQL語句，會看到SQL是這樣的：

SELECT id,title,author,content FROM blog WHERE id = ?
複製代碼

無論輸入什麼參數，打印出的SQL都是這樣的。這是由於MyBatis啓用了預編譯功能，在SQL執行前，會先將上面的SQL發送給數據庫進行編譯；執行時，直接使用編譯好的SQL，替換佔位符「?」就能夠了。由於SQL注入只能對編譯過程起做用，因此這樣的方式就很好地避免了SQL注入的問題。

【底層實現原理】MyBatis是如何作到SQL預編譯的呢？其實在框架底層，是JDBC中的PreparedStatement類在起做用，PreparedStatement是咱們很熟悉的Statement的子類，它的對象包含了編譯好的SQL語句。這種「準備好」的方式不只能提升安全性，並且在屢次執行同一個SQL時，可以提升效率。緣由是SQL已編譯好，再次執行時無需再編譯。

話說回來，是否咱們使用MyBatis就必定能夠防止SQL注入呢？固然不是，請看下面的代碼：

<select id="getBlogById" resultType="Blog" parameterType=」int」>

         SELECT id,title,author,content

         FROM blog

WHERE id=${id}

</select>
複製代碼

仔細觀察，內聯參數的格式由「#{xxx}」變爲了「${xxx}」。若是咱們給參數「id」賦值爲「3」，將SQL打印出來是這樣的：

SELECT id,title,author,content FROM blog WHERE id = 3
複製代碼

（上面的對比示例是我本身添加的，爲了與前面的示例造成鮮明的對比。）

<select id="orderBlog" resultType="Blog" parameterType=」map」>

         SELECT id,title,author,content

         FROM blog

ORDER BY ${orderParam}

</select>
複製代碼

仔細觀察，內聯參數的格式由「#{xxx}」變爲了「${xxx}」。若是咱們給參數「orderParam」賦值爲「id」，將SQL打印出來是這樣的：

SELECT id,title,author,content FROM blog ORDER BY id
複製代碼

顯然，這樣是沒法阻止SQL注入的。在MyBatis中，「${xxx}」這樣格式的參數會直接參與SQL編譯，從而不能避免注入攻擊。但涉及到動態表名和列名時，只能使用「${xxx}」這樣的參數格式。因此，這樣的參數須要咱們在代碼中手工進行處理來防止注入。

【結論】在編寫MyBatis的映射語句時，儘可能採用「#{xxx}」這樣的格式。若不得不使用「${xxx}」這樣的參數，要手工地作好過濾工做，來防止SQL注入攻擊。

#{}：至關於JDBC中的PreparedStatement

${}：是輸出變量的值
複製代碼

簡單說，#{}是通過預編譯的，是安全的；${}是未通過預編譯的，僅僅是取變量的值，是非安全的，存在SQL注入。

若是咱們order by語句後用了${}，那麼不作任何處理的時候是存在SQL注入危險的。你說怎麼防止，那我只能悲慘的告訴你，你得手動處理過濾一下輸入的內容。如判斷一下輸入的參數的長度是否正常（注入語句通常很長），更精確的過濾則能夠查詢一下輸入的參數是否在預期的參數集合中。