sql注入是一种很简单的攻击手段，但直到今天仍然十分常见。究其原因不外乎：no patch for stupid。为什么这么说，下面就以java为例进行说明：
假设数据库中存在这样的表：
|
1
2
3
4
|
table user( id varchar(20) primary key , name varchar(20) , age varchar(20) ); |
然后使用jdbc操作表：
|
1
2
3
4
5
6
7
|
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语句如下：
|
1
|
select name from user where id=3; drop table user; |
数据库在编译执行之后，删除了user表。瞧,一个简单的sql注入攻击生效了！之所以这样，是因为上面的代码没有符合编程规范。
当我们按照规范编程时，sql注入就不存在了。这也是避免sql注入的第一种方式：预编译语句，代码如下：
|
1
2
3
4
5
6
|
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注入攻击
|
1
2
3
4
5
6
|
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); |
上面的代码中对应的存储过程如下：
|
1
2
3
4
5
6
7
8
|
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文件为：
|
1
2
3
|
<select id="getnamebyuserid" resulttype="string"> select name from user where id = #{userid} </select> |
对应的java文件为：
|
1
2
3
|
public interface usermapper{ string getnamebyuserid(@param("userid") string userid); } |
可以看到输入的参数是string类型的userid,当我们传入userid="34;drop table user;"后，打印的语句是这样的：
|
1
|
select name from user where id = ? |
不管输入何种userid，他的sql语句都是这样的。这就得益于mybatis在底层实现时使用预编译语句。数据库在执行该语句时，直接使用预编译的语句，然后用传入的userid替换占位符？就去运行了。不存在先替换占位符？再进行编译的过程，因此sql注入也就没有了生存的余地了。
那么mybatis是如何做到sql预编译的呢？其实框架底层使用的正是preparedstatement类。preparedstaement类不但能够避免sql注入，因为已经预编译，当n次执行同一条sql语句时,节约了(n-1)次的编译时间，从而能够提高效率。
如果将上面的语句改成：
|
1
2
3
|
<select id="getnamebyuserid" resulttype="string"> select name from user where id = ${userid} </select> |
当我们输入userid="34;drop table user;"后，打印的语句是这样的：
|
1
|
select name from user where id = 34;drop table user; |
此时，mybatis没有使用预编译语句，它会先进行字符串拼接再执行编译，这个过程正是sql注入生效的过程。
因此在编写mybatis的映射语句时，尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止sql注入攻击。
总结
以上所述是小编给大家介绍的mybatis防止sql注入的方法实例详解，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对服务器之家网站的支持！
原文链接：https://blog.csdn.net/bwh0520/article/details/80102040
