mybatis是如何防止SQL注入的

SQL注入是一种很简单的攻击手段，但直到今天仍然十分常见。究其原因不外乎： No patch for stupid 。为什么这么说，下面就以JAVA为例进行说明：

假设数据库中存在这样的表：

[java]  view plain  copy

1. table user(  
2. id   varchar(20)    PRIMARY KEY ,         
3. name     varchar(20)            ,  
4. age  varchar(20)           );  

然后使用JDBC操作表：

[java]  view plain  copy

1. private String getNameByUserId(String userId) {  
2.     Connection conn = getConn();//获得连接  
3.     String sql = "select name from user where id=" + userId;  
4.     PreparedStatement pstmt =  conn.prepareStatement(sql);  
5.     ResultSet rs=pstmt.executeUpdate();  
6.     ......  
7. }  

上面的代码经常被一些开发人员使用。想象这样的情况，当传入的userId参数为"3;drop table user;"时，执行的sql语句如下：

[java]  view plain  copy

1. select name from user where id=3; drop table user;  

数据库在编译执行之后，删除了user表。瞧,一个简单的SQL注入攻击生效了！之所以这样，是因为上面的代码没有符合编程规范。

当我们按照规范编程时，SQL注入就不存在了。这也是 避免SQL注入的第一种方式：预编译语句 ，代码如下：

[java]  view plain  copy

1.    Connection conn = getConn();//获得连接  
2. String sql = "select name from user where id= ?";  
3. PreparedStatement pstmt = conn.prepareStatement(sql);  
4. pstmt.setString(1, userId);  
5. ResultSet rs=pstmt.executeUpdate();  
6. ......  

为什么上面的代码就不存在SQL注入了呢？因为使用了预编译语句，预编译语句在执行时会把"select name from user where id= ?"语句事先编译好，这样当执行时仅仅需要用传入的参数替换掉？占位符即可。而对于第一种不符合规范的情况，程序会先生成sql语句，然后带着用户传入的内容去编译，这恰恰是问题所在。

除了使用预编译语句之外，还有 第二种避免SQL注入攻击的方式：存储过程。 存储过程（Stored Procedure）是一组完成特定功能的SQL语句集，经编译后存储在数据库中，用户通过调用存储过程并给定参数（如果该存储过程带有参数）就可以执行它，也可以避免SQL注入攻击

[java]  view plain  copy

1.    Connection conn = getConn();  
2. stmt = conn.prepareCall("{call name_from_user(?,?)}");    
3. stmt.setInt(1,2);    
4. stmt.registerOutParameter(2, Types.VARCHAR);    
5. stmt.execute();    
6. String name= stmt.getString(2);   

上面的代码中对应的存储过程如下：

[java]  view plain  copy

1. use user;  
2. delimiter //  
3. create  procedure name_from_user(in user_id int,out user_name varchar(20))  
4. begin  
5.     select name into user_name from user where id=user_id;  
6. end  
7. //  
8. delimiter ;  

当然用户也可以在 前端做字符检查，这也是一种避免SQL注入的方式 ：比如对于上面的userId参数，用户检查到包含分号就提示错误。
不过，从最根本的原因看，SQL注入攻击之所以存在，是因为 app在访问数据库时没有使用最小权限 。想来也是，大家好像一直都在使用root账号访问数据库。

那么mybatis是如何避免sql注入攻击的呢？还是以上面的表user为例：
假设mapper文件为：

[java]  view plain  copy

1. <select id="getNameByUserId" resultType="String">  
2.         SELECT name FROM user where id = #{userId}  
3. </select>  

对应的java文件为：

[java]  view plain  copy

1. public interface UserMapper{  
2.     String getNameByUserId(@Param("userId") String userId);  
3. }  

可以看到输入的参数是String类型的userId,当我们传入userId="34;drop table user;"后，打印的语句是这样的：

[java]  view plain  copy

1. select name from user where id = ?  

不管输入何种userID，他的sql语句都是这样的。这就得益于mybatis在底层实现时使用预编译语句。数据库在执行该语句时，直接使用预编译的语句，然后用传入的userId替换占位符？就去运行了。不存在先替换占位符？再进行编译的过程，因此SQL注入也就没有了生存的余地了。

那么mybatis是如何做到sql预编译的呢？其实框架底层使用的正是PreparedStatement类。PreparedStaement类不但能够避免SQL注入，因为已经预编译，当N次执行同一条sql语句时,节约了(N-1)次的编译时间，从而能够提高效率。

如果将上面的语句改成：

[java]  view plain  copy

1. <select id="getNameByUserId" resultType="String">  
2.         SELECT name FROM user where id = ${userId}  
3. </select>  

当我们输入userId="34;drop table user;"后，打印的语句是这样的：

[java]  view plain  copy

1. select name from user where id = 34;drop table user;  

此时，mybatis没有使用预编译语句，它会先进行字符串拼接再执行编译，这个过程正是SQL注入生效的过程。
因此在编写mybatis的映射语句时，尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止sql注入攻击。