mybatis防sql注入

⑴ MyBatis如何防止SQL注入

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



[摘自] mybatis的#{}和${}的區別以及order by注入問題

#{}：相當於JDBC中的PreparedStatement

${}：是輸出變數的值

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

如果我們order by語句後用了${}，那麼不做任何處理的時候是存在SQL注入危險的。你說怎麼防止，那我只能悲慘的告訴你，你得手動處理過濾一下輸入的內容。如判斷一下輸入的參數的長度是否正常（注入語句一般很長），更精確的過濾則可以查詢一下輸入的參數是否在預期的參數集合中。
MyBatis如何防止SQL注入
標簽：轉儲如何bsp表單攻擊cep添加typeback