【安全】mybatis中#{}和${}导致sql注入问题及解决办法

0.问题

使用mybatis的时候遇到了#{}和${}可能导致sql注入的问题

1.预先了解

(1)#{}

  • #{} 底层通过prepareStatement对当前传入的sql进行了预编译,一个 #{ } 被解析为一个参数占位符 ?;
  • #{} 解析之后会将String类型的数据自动加上引号,其他数据类型不会
  • #{} 很大程度上可以防止sql注入(sql注入是发生在编译的过程中,因为恶意注入了某些特殊字符,最后被编译成了恶意的执行操作)
  • #{} 一般用在insert的字段和where条件中,用来防止sql注入

(2)${}

  • ${}仅仅为一个纯粹的 string 替换,在动态sql解析阶段将会进行变量替换
  • ${} 解析之后是什么就是什么
  • ${} 用在sql字符串拼接中,使用时需要非常谨慎。但是像一些没有直接和系统用户接触的功能如动态切换表名,库名呀就不存在注入问题了。一旦要使用在要被用户直接接触的sql中,一定要注意!

2.举个栗子

(1)${}

1)sql注入

@Select("select * from user where name = ${name}")
List<User> sqltest1(String name);

如果传进去的参数是

name = "1' OR 1='1";

那么数据库最后执行的语句则为

select * from user where name = '1' OR 1='1 ';

会直接导致sql注入,被攻击者成功登录

2)语句堵塞

@Select("select * from user order by ${column}")
List<User> sqltest1(String column);

如果传进去的参数是

column = "id,(select 1 from (select sleep(1000))a)"

那么数据库最后执行的语句则为

select * from user order by id,(select 1 from (select sleep(1000))a)

可以发现程序会阻塞1000秒,被攻击者造成语句堵塞

(2)#{}

1)无法执行

   @Select("select * from user order by #{column}")
    List<User> sqltest1(String column);

如果传进去的参数是

column = "name";

那么#{}会自动给参数加上单引号,数据库语句变成

select * from user order by 'name'

无法正常执行

2)无法执行

@Select("select * from user where name like '%#{name}%'")
List<User> sqltest2(String name);

如果传入的参数为

name = "yin";

那么数据库语句就变成

select * from user where name like '%'name'%'

直接报错,无法执行

3.解决办法

正常来看,一般的解决方法可以使用#{}来代替${},但是有的语句如果使用#{}会造成语句错误(因为#{}会将String类型的参数加上单引号)。必须要使用${}的有动态指定order by 排序字段、和like模糊匹配,但是这种方式会带来sql注入问题。具体解决方法如下:

(1)动态指定order by 排序字段

自定义一个Map,存入的key为前端传过来的值,value则是参与自定义排序的字段名。真正进行自定义排序的时候使用这个map即可。

// key为前端传的值,value为数据库对应的列值
    public static Map<String,String> orderByKeyMap = new HashMap<String,String>(){
        {
            put("userId","id");
            put("name","name");
        }
@Select("select * from user order by #{column}")
List<User> sqltest1(String column);
 List<User> users = mapper.sqltest3(User.orderByKeyMap.get("name"));

这样就不会出错了

(2)like模糊匹配

可以使用concat来拼接#{}的字符串,这样就不会报错,也不会导致索引失效

 @Select("select * from user where name like concat('%',#{name},'%')")
List<User> sqltest2(String name);

参入参数

name = "yin";

执行的语句就编程

select * from user where name like concat('%','yin','%');

这样就解决问题了

4.如何防止sql注入?

1. 使用预编译机制

尽量用预编译机制,少用字符串拼接的方式传参,它是sql注入问题的根源。

2. 要对特殊字符转义

有些特殊字符,比如:%作为like语句中的参数时,要对其进行转义处理。

3. 要捕获异常

需要对所有的异常情况进行捕获,切记接口直接返回异常信息,因为有些异常信息中包含了sql信息,包括:库名,表名,字段名等。攻击者拿着这些信息,就能通过sql注入随心所欲的攻击你的数据库了。目前比较主流的做法是,有个专门的网关服务,它统一暴露对外接口。用户请求接口时先经过它,再由它将请求转发给业务服务。这样做的好处是:能统一封装返回数据的返回体,并且如果出现异常,能返回统一的异常信息,隐藏敏感信息。此外还能做限流和权限控制。

4. 使用代码检测工具

使用sqlMap等代码检测工具,它能检测sql注入漏洞。

5. 要有监控

需要对数据库sql的执行情况进行监控,有异常情况,及时邮件或短信提醒。

6. 数据库账号需控制权限

对生产环境的数据库建立单独的账号,只分配DML相关权限,且不能访问系统表。切勿在程序中直接使用管理员账号。

7. 代码review

建立代码review机制,能找出部分隐藏的问题,提升代码质量。

8. 使用其他手段处理

对于不能使用预编译传参时,要么开启druid的filter防火墙,要么自己写代码逻辑过滤掉所有可能的注入关键字。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>