關於Mybatis如何防止sql注入的程式碼案例

本文透過實例介紹了Mybatis防止sql注入的相關資料,非常不錯，具有參考借鑒價值，需要的朋友可以參考下

sql注入大家都不陌生，是一種常見的攻擊方式，攻擊者在介面的表單資訊或url上輸入一些奇怪的sql片段，例如「or '1'='1'」這樣的語句，有可能入侵參數校驗不足的應用程式。所以在我們的應用上需要做一些工作，來防備這樣的攻擊方式。在一些安全性性很高的應用中，例如銀行軟體，經常使用將sql語句全部替換為預存程序這樣的方式，來防止sql注入，這當然是一種很安全的方式，但我們平時開發中，可能不需要這種死板的方式。

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="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注入攻擊。

以上是關於Mybatis如何防止sql注入的程式碼案例的詳細內容。更多資訊請關注PHP中文網其他相關文章！