SQL注入是一種代碼注入技術，用於攻擊數據驅動的應用，惡意的SQL語句被插入到執行的實體字段中（例如，爲了轉儲數據庫內容給攻擊者）。[摘自] SQL injection - Wikipedia
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="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注入危險的。你說怎麼防止，那我只能悲慘的告訴你，你得手動處理過濾一下輸入的內容。如判斷一下輸入的參數的長度是否正常（注入語句一般很長），更精確的過濾則可以查詢一下輸入的參數是否在預期的參數集合中。
還有一種方法防sql注入：
採用阿里的druid數據連接池添加防sql注入配置
<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close">
<!-- 數據源驅動類可不寫，Druid默認會自動根據URL識別DriverClass -->
<property name="driverClassName" value="${jdbc.driver}" />
<!-- 基本屬性 url、user、password -->
<property name="url" value="${jdbc.url}" />
<property name="username" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
<!-- 配置初始化大小、最小、最大 -->
<property name="initialSize" value="${jdbc.initialSize}" />
<property name="minIdle" value="${jdbc.minIdle}" />
<property name="maxActive" value="${jdbc.maxActive}" />
<!-- 配置獲取連接等待超時的時間 -->
<property name="maxWait" value="${jdbc.maxWait}" />
<!-- 配置間隔多久才進行一次檢測，檢測需要關閉的空閒連接，單位是毫秒 -->
<property name="timeBetweenEvictionRunsMillis" value="${jdbc.timeBetweenEvictionRunsMillis}" />
<!-- 配置一個連接在池中最小生存的時間，單位是毫秒 -->
<property name="minEvictableIdleTimeMillis" value="${jdbc.minEvictableIdleTimeMillis}" />
<property name="validationQuery" value="${jdbc.testSql}" />
<property name="testWhileIdle" value="true" />
<property name="testOnBorrow" value="false" />
<property name="testOnReturn" value="false" />
<!-- 打開PSCache，並且指定每個連接上PSCache的大小 -->
<property name="poolPreparedStatements" value="true" />
<property name="maxPoolPreparedStatementPerConnectionSize" value="20" />
<!-- 配置監控統計攔截的filters,和防sql注入 -->
<property name="filters" value="stat,wall" />
</bean>