阅读正文：

mybatis 是如何防止 SQL 注入的

1、首先看一下下面两个 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 中的 #和 $ 的区别：

1、# 将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。
如：where username=#{username}，如果传入的值是 111, 那么解析成 sql 时的值为 where username="111", 如果传入的值是 id，则解析成的 sql 为 where username="id".　
2、$ 将传入的数据直接显示生成在 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、$ 方式一般用于传入数据库对象，例如传入表名.
5、一般能用 #的就别用 $，若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止 sql 注入攻击。
6、在 MyBatis 中，“${xxx}”这样格式的参数会直接参与 SQL 编译，从而不能避免注入攻击。但涉及到动态表名和列名时，只能使用“${xxx}”这样的参数格式。所以，这样的参数需要我们在代码中手工进行处理来防止注入。
【结论】在编写 MyBatis 的映射语句时，尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止 SQL 注入攻击。

2、什么是 sql 注入

　　 sql 注入解释：是一种代码注入技术，用于攻击数据驱动的应用，恶意的 SQL 语句被插入到执行的实体字段中（例如，为了转储数据库内容给攻击者）

　　SQL注入，大家都不陌生，是一种常见的攻击方式。攻击者在界面的表单信息或 URL 上输入一些奇怪的 SQL 片段（例如“or ‘1’=’1’”这样的语句），有可能入侵参数检验不足的应用程序。所以，在我们的应用中需要做一些工作，来防备这样的攻击方式。在一些安全性要求很高的应用中（比如银行软件），经常使用将SQL语句全部替换为存储过程这样的方式，来防止 SQL 注入。这当然是一种很安全的方式，但我们平时开发中，可能不需要这种死板的方式。

3、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();
    ......
}

【 结论：】

简单说，#{} 是经过预编译的，是安全的；${} 是未经过预编译的，仅仅是取变量的值，是非安全的，存在 SQL 注入。
如果我们 order by 语句后用了 ${}，那么不做任何处理的时候是存在 SQL 注入危险的。你说怎么防止，那我只能悲惨的告诉你，你得手动处理过滤一下输入的内容。如判断一下输入的参数的长度是否正常（注入语句一般很长），更精确的过滤则可以查询一下输入的参数是否在预期的参数集合中。

4、参考文章

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

https://www.cnblogs.com/200911/p/5869097.html

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