mybatis是如何防止SQL注入的

mybatis是如何防止SQL注入的

一、首先看一下下面兩個sql語句的區別：

<select id="selectByNameAndPassword" parameterType="java.util.Map" resultMap="BaseResultMap">
select id, username, password, role
from user
where username = #{username,jdbcType=VARCHAR}
and password = #{password,jdbcType=VARCHAR}
</select>

<select id="selectByNameAndPassword" parameterType="java.util.Map" resultMap="BaseResultMap">
select id, username, password, role
from user
where username = ${username,jdbcType=VARCHAR}
and password = ${password,jdbcType=VARCHAR}
</select>

mybatis中的#和$的區別：

一、#將傳入的數據都當成一個字符串，會對自動傳入的數據加一個雙引號。
如：where username=#{username}，若是傳入的值是111,那麼解析成sql時的值爲where username="111", 若是傳入的值是id，則解析成的sql爲where username="id".　
二、$將傳入的數據直接顯示生成在sql中。
如：where username=${username}，若是傳入的值是111,那麼解析成sql時的值爲where username=111；
若是傳入的值是;drop table user;，則解析成的sql爲：select id, username, password, role from user where username=;drop table user;
三、#方式可以很大程度防止sql注入，$方式沒法防止Sql注入。
四、$方式通常用於傳入數據庫對象，例如傳入表名.
五、通常能用#的就別用$，若不得不使用「${xxx}」這樣的參數，要手工地作好過濾工做，來防止sql注入攻擊。
六、在MyBatis中，「${xxx}」這樣格式的參數會直接參與SQL編譯，從而不能避免注入攻擊。但涉及到動態表名和列名時，只能使用「${xxx}」這樣的參數格式。因此，這樣的參數須要咱們在代碼中手工進行處理來防止注入。
【結論】在編寫MyBatis的映射語句時，儘可能採用「#{xxx}」這樣的格式。若不得不使用「${xxx}」這樣的參數，要手工地作好過濾工做，來防止SQL注入攻擊。

二、什麼是sql注入

　　 sql注入解釋：是一種代碼注入技術，用於攻擊數據驅動的應用，惡意的SQL語句被插入到執行的實體字段中（例如，爲了轉儲數據庫內容給攻擊者）

　　SQL注入，你們都不陌生，是一種常見的攻擊方式。攻擊者在界面的表單信息或URL上輸入一些奇怪的SQL片斷（例如「or ‘1’=’1’」這樣的語句），有可能入侵參數檢驗不足的應用程序。因此，在咱們的應用中須要作一些工做，來防備這樣的攻擊方式。在一些安全性要求很高的應用中（好比銀行軟件），常用將SQL語句所有替換爲存儲過程這樣的方式，來防止SQL注入。這固然是一種很安全的方式，但咱們平時開發中，可能不須要這種死板的方式。

三、mybatis是如何作到防止sql注入的

　　MyBatis框架做爲一款半自動化的持久層框架，其SQL語句都要咱們本身手動編寫，這個時候固然須要防止SQL注入。其實，MyBatis的SQL是一個具備「輸入+輸出」的功能，相似於函數的結構，參考上面的兩個例子。其中，parameterType表示了輸入的參數類型，resultType表示了輸出的參數類型。迴應上文，若是咱們想防止SQL注入，理所固然地要在輸入參數上下功夫。上面代碼中使用#的即輸入參數在SQL中拼接的部分，傳入參數後，打印出執行的SQL語句，會看到SQL是這樣的：

select id, username, password, role from user where username=? and password=?

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

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

//安全的，預編譯了的
Connection conn = getConn();//得到鏈接
String sql = "select id, username, password, role from user where id=?"; //執行sql前會預編譯號該條語句
PreparedStatement pstmt = conn.prepareStatement(sql); 
pstmt.setString(1, id); 
ResultSet rs=pstmt.executeUpdate(); 
......

//不安全的，沒進行預編譯
private String getNameByUserId(String userId) {
    Connection conn = getConn();//得到鏈接
    String sql = "select id,username,password,role from user where id=" + id;
    //當id參數爲"3;drop table user;"時，執行的sql語句以下:
    //select id,username,password,role from user where id=3; drop table user;  
    PreparedStatement pstmt =  conn.prepareStatement(sql);
    ResultSet rs=pstmt.executeUpdate();
    ......
}

【 結論：】

#{}：至關於JDBC中的PreparedStatement

${}：是輸出變量的值

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

四、參考文章

http://blog.csdn.net/yizhenn/article/details/52384601

http://www.javashuo.com/article/p-ycjoxoah-en.html

http://www.jb51.net/article/95314.htm