1、首先看一下下面兩個sql語句的區(qū)別：

<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中的#和$的區(qū)別：

• 1、#將傳入的數(shù)據(jù)都當成一個字符串，會對自動傳入的數(shù)據(jù)加一個雙引號。
  如：where username=#{username}，如果傳入的值是111,那么解析成sql時的值為where username="111", 如果傳入的值是id，則解析成的sql為where username="id".　
• 2、$將傳入的數(shù)據(jù)直接顯示生成在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;
• 3、#方式能夠很大程度防止sql注入，$方式無法防止Sql注入。
• 4、$方式一般用于傳入數(shù)據(jù)庫對象，例如傳入表名.
• 5、一般能用#的就別用$，若不得不使用“${xxx}”這樣的參數(shù)，要手工地做好過濾工作，來防止sql注入攻擊。
• 6、在MyBatis中，“${xxx}”這樣格式的參數(shù)會直接參與SQL編譯，從而不能避免注入攻擊。但涉及到動態(tài)表名和列名時，只能使用“${xxx}”這樣的參數(shù)格式。所以，這樣的參數(shù)需要我們在代碼中手工進行處理來防止注入。

【結論】在編寫MyBatis的映射語句時，盡量采用“#{xxx}”這樣的格式。若不得不使用“${xxx}”這樣的參數(shù)，要手工地做好過濾工作，來防止SQL注入攻擊。

2、什么是sql注入

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

SQL注入，大家都不陌生，是一種常見的攻擊方式。攻擊者在界面的表單信息或URL上輸入一些奇怪的SQL片段（例如“or ‘1'='1'”這樣的語句），有可能入侵參數(shù)檢驗不足的應用程序。所以，在我們的應用中需要做一些工作，來防備這樣的攻擊方式。在一些安全性要求很高的應用中（比如銀行軟件），經(jīng)常使用將SQL語句全部替換為存儲過程這樣的方式，來防止SQL注入。這當然是一種很安全的方式，但我們平時開發(fā)中，可能不需要這種死板的方式。

3、mybatis是如何做到防止sql注入的

MyBatis框架作為一款半自動化的持久層框架，其SQL語句都要我們自己手動編寫，這個時候當然需要防止SQL注入。其實，MyBatis的SQL是一個具有“輸入+輸出”的功能，類似于函數(shù)的結構，參考上面的兩個例子。其中，parameterType表示了輸入的參數(shù)類型，resultType表示了輸出的參數(shù)類型?；貞衔模绻覀兿敕乐筍QL注入，理所當然地要在輸入?yún)?shù)上下功夫。上面代碼中使用#的即輸入?yún)?shù)在SQL中拼接的部分，傳入?yún)?shù)后，打印出執(zhí)行的SQL語句，會看到SQL是這樣的：

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

不管輸入什么參數(shù)，打印出的SQL都是這樣的。這是因為MyBatis啟用了預編譯功能，在SQL執(zhí)行前，會先將上面的SQL發(fā)送給數(shù)據(jù)庫進行編譯；執(zhí)行時，直接使用編譯好的SQL，替換占位符“?”就可以了。因為SQL注入只能對編譯過程起作用，所以這樣的方式就很好地避免了SQL注入的問題。

【底層實現(xiàn)原理】MyBatis是如何做到SQL預編譯的呢？其實在框架底層，是JDBC中的PreparedStatement類在起作用，PreparedStatement是我們很熟悉的Statement的子類，它的對象包含了編譯好的SQL語句。這種“準備好”的方式不僅能提高安全性，而且在多次執(zhí)行同一個SQL時，能夠提高效率。原因是SQL已編譯好，再次執(zhí)行時無需再編譯。

//安全的，預編譯了的
Connection conn = getConn();//獲得連接
String sql = "select id, username, password, role from user where id=?"; //執(zhí)行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參數(shù)為"3;drop table user;"時，執(zhí)行的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

${}：是輸出變量的值

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

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

4、參考文章

http://www.fzitv.net/article/231031.htm

http://www.fzitv.net/article/231025.htm

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

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論