本文大纲:
- 先分析什么是SQL注入漏洞?
- 再分析#{}和${}之间的区别
- 再基于MybatisPlus做验证
- 再介绍#{}和${}的使用场景
什么是SQL注入?
先看两段代码,假如id的值为字符串"100",大家可以顺便想想每段代码最后拼接出来的SQL长什么样。
字符串直接拼接参数
public static ResultSet executeInject(Connection connection, String id) {
String sql = "select * from order_info where id = " + id;
PreparedStatement stmt = connection.prepareStatement(sql);
return stmt.executeQuery();
}
通过占位符?和setString()方法拼接参数
public static ResultSet executeNormal(Connection connection, String id) {
String sql = "select * from order_info where id = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, id);
return stmt.executeQuery();
}
这两种方式有什么不同吗?
假如id的值是字符串"100",那么以上两段代码最终拼出来的SQL为:
字符串直接拼接参数的结果:
"select * from order_info where id = 100"
通过占位符?和setString()方法拼接参数的结果:
"select * from order_info where id = '100'"
看上去区别不大,但是对于
id=100
来说,id是varchar,100是int,对于mysql来说是要做类型转换的,这个过程其实是会导致问题的,下篇文章再来分析,关注我的公众号:IT周瑜
那如果现在小勇乱写,他给id传的值为"100 or 1=1",那么拼出来的SQL为:
字符串直接拼接参数的结果:
"select * from order_info where id = 100 or 1=1"
通过占位符?和setString()方法拼接参数的结果:
"select * from order_info where id = '100 or 1=1'"
仔细看看,看出区别没,直接拼接参数的将能查出全部数据,因为or 1=1
生效了,而通过?和setString拼接的则不会出现问题,因为它被包裹在’'里了,而这就是SQL注入漏洞。
${}和#{}的区别
那以上两种情况和${}和#{}是什么关系呢?是一对一的关系。
${}对应的就是字符串直接拼接参数,从而会有SQL注入的风险。
#{}对应的就是占位符?和setString()拼接参数,不会有SQL注入的风险。
怎么验证呢?回头系统给大家分析下源码,今天先通过Demo来验证。
开启MybatisPlus的日志打印,先测试${}符号:
select * from order_info where id = ${id}
id为"10",结果为(正常查出一条):
id为"10 or 1=1",结果为(查出了全部数据,or 1=1生效了,发生了SQL注入):
再来测试#{}符号:
select * from order_info where id = #{id}
id为"10",结果为(正常查出一条):
id为"10 or 1=1",结果为(没有查出全部数据):
不过为啥最后这种情况,**正常应该是查不出来数据的,为啥还查出了一条数据呢?**我先提示一下,跟我的数据库id字段类型有关,id是int类型,你知道原因吗?答案跟本文没有太大关系,所以我会再下篇文章来分析这个问题,想要不错过我的文章,关注我的公众号:IT周瑜。
使用场景总结
那#{}和${}实际工作中到底该如何使用呢?
建议在where条件后尽量使用#{},用来防止SQL注入。
${}可以用在select之后,用来动态传入待查询字段,比如select ${col} where...
,如果col的值为"name",那么拼出来的sql为select name where...
,这是正常的,而如果用#{}拼出来的就是select 'name' where...\
,变成了固定返回"name"这个字符串了,反倒是有问题的。
一个炫酷的360度ending pose~
我是IT周瑜,我们下次见。
最近有点忙,转正答辩、公司内部培训、调研RPA、流量回放、时序数据库等等,文章更新频率低了,后面应该会好点了,持续学习,持续分享。