mybatis是如何防止SQL注入的

SQL注入是一种很简单的攻击手段，但直到今天仍然十分常见。究其缘由不外乎：No patch for stupid。

为何这么说，下面就以JAVA为例进行说明：

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

table user( id varchar(20) PRIMARY KEY ,

name varchar(20) ,

age varchar(20) );

而后使用JDBC操做表：

private String getNameByUserId(String userId) {

Connection conn = getConn;//得到链接

String sql = "select name from user where id=" + userId;

PreparedStatement pstmt = conn.prepareStatement(sql);

ResultSet rs=pstmt.executeUpdate; ......

}

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

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

数据库在编译执行以后，删除了user表。瞧,一个简单的SQL注入攻击生效了！之因此这样，是由于上面的代码没有符合编程规范。 当咱们按照规范编程时，SQL注入就不存在了。

这也是避免SQL注入的第一种方式：

预编译语句，代码以下：

Connection conn = getConn;//得到链接

String sql = "select name from user where id= ?";

PreparedStatement pstmt = conn.prepareStatement(sql);

pstmt.setString(1, userId);

ResultSet rs=pstmt.executeUpdate; ......

为何上面的代码就不存在SQL注入了呢？由于使用了预编译语句，预编译语句在执行时会把"select name from user where id= ?"语句事先编译好，这样当执行时仅仅须要用传入的参数替换掉？占位符便可。

而对于第一种不符合规范的状况，程序会先生成sql语句，而后带着用户传入的内容去编译，这偏偏是问题所在。 除了使用预编译语句以外，还有第二种避免SQL注入攻击的方式：存储过程。

存储过程（Stored Procedure）是一组完成特定功能的SQL语句集，经编译后存储在数据库中，用户经过调用存储过程并给定参数（若是该存储过程带有参数）就能够执行它，也能够避免SQL注入攻击

Connection conn = getConn;

stmt = conn.prepareCall("{call name_from_user(?,?)}");

stmt.setInt(1,2);

stmt.registerOutParameter(2, Types.VARCHAR);

stmt.execute;

String name= stmt.getString(2);

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

use user; delimiter // create procedure name_from_user(in user_id int,out user_name varchar(20)) begin select name into user_name from user where id=user_id; end // delimiter ; 固然用户也能够在前端作字符检查，这也是一种避免SQL注入的方式：好比对于上面的userId参数，用户检查到包含分号就提示错误。

不过，从最根本的缘由看，SQL注入攻击之因此存在，是由于app在访问数据库时没有使用最小权限。想来也是，你们好像一直都在使用root帐号访问数据库。 那么mybatis是如何避免sql注入攻击的呢？仍是以上面的表user为例： 假设mapper文件为：

SELECT name FROM user where id = #{userId} 对应的java文件为：

public interface UserMapper{ String getNameByUserId(@Param("userId") String userId); }

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

select name from user where id = ? 无论输入何种userID，他的sql语句都是这样的。

这就得益于mybatis在底层实现时使用预编译语句。数据库在执行该语句时，直接使用预编译的语句，而后用传入的userId替换占位符？就去运行了。不存在先替换占位符？再进行编译的过程，所以SQL注入也就没有了生存的余地了。

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

若是将上面的语句改为： SELECT name FROM user where id = ${userId} 当咱们输入userId="34;drop table user;"后，打印的语句是这样的： select name from user where id = 34;drop table user; 此时，mybatis没有使用预编译语句，它会先进行字符串拼接再执行编译，这个过程正是SQL注入生效的过程。

所以在编写mybatis的映射语句时，尽可能采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数，要手工地作好过滤工做，来防止sql注入攻击。