mybatis中 为什么#{}能防止SQL注入 而 ${}不行

mybatis · 2021-01-13 · 543 人浏览

什么是SQL注入以及mybatis中#{}为什么能防止SQL注入而${}为什么不能防止SQL注入

SQL注入是通过把SQL命令插入到web表单提交或通过页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL指令。

  注入攻击的本质是把用户输入的数据当做代码执行。

  举例如: 表单有两个用户需要填写的表单数据,用户名和密码,如果用户输入admin(用户名),111(密码),若数据库中存在此用户则登录成功。SQL大概是这样

      SELECT * FROM XXX WHERE userName = admin and password = 111

     但若是遭到了SQL注入,输入的数据变为  admin or 1 =1 # 密码随便输入,这时候就直接登录了,SQL大概是这样

      SELECT * FROM XXX WHERE userName = admin or 1 = 1 # and password = 111 ,因为 # 在sql语句中是注释,将后面密码的验证去掉了,而前面的条件中1 = 1始终成立,所以不管密码正确与否,都能登录成功。

在mybatis中,${param}这样格式的参数会直接参与sql编译,从而不能避免注入攻击。但涉及到动态表名和列名时,只能使用${param}这样的参数格式,所以,这样的参数需要程序开发者在代码中手工进行处理来防止注入。

#{param} 代表param是属性值,map里面的key或者是你的pojo对象里面的属性, mybatis会自动在它的外面加上引号,表现在sql语句是这样的 where column = 'param' ;

${param} 则是把param作为字符串拼接到sql语句中, 比如 order by topicId ,

语句这样写: order by #{param}  , mybatis 就会翻译成 order by 'topicId' (这样就会报错)

语句这样写 ... order by ${param} , mybatis 就会翻译成 order by topicId

#:将传入的数据都当成一个字符串,会对自动传入的数据加一个双引号。如:order by #user_id#,如果传入的值是111,那么解析成sql时的值为order by "111", 如果传入的值是id,则解析成的sql为order by "id".  

$:将传入的数据直接显示生成在sql中。如:order by $user_id$,如果传入的值是111,那么解析成sql时的值为order by user_id, 如果传入的值是id,则解析成的sql为order by id