mybatis中#{}与${}的差别(如何防止sql注入)

默认情况下,使用#{}语法,MyBatis会产生PreparedStatement语句中,并且安全的设置PreparedStatement参数,这个过程中MyBatis会进行必要的安全检查和转义。

#相当于对数据 加上 双引号,$相当于直接显示数据

示例1:
执行SQL:select * from emp where name = #{employeeName}
参数:employeeName=>Smith
解析后执行的SQL:select * from emp where name = ?

示例2:

执行SQL:select * from emp where name = ${employeeName}
参数:employeeName传入值为:Smith
解析后执行的SQL:Select * from emp where name =Smith

 

综上所述、${}方式会引发SQL注入的问题、同时也会影响SQL语句的预编译,所以从安全性和性能的角度出发,能使用#{}的情况下就不要使用${}

Q:但是${}在什么情况下使用呢?

A:有时候可能需要直接插入一个不做任何修改的字符串到SQL语句中。这时候应该使用${}语法。

  比如,动态SQL中的字段名,如:ORDER BY ${columnName}

 

重要:接受从用户输出的内容并提供给语句中不变的字符串,这样做是不安全的。这会导致潜在的SQL注入攻击,因此你不应该允许用户输入这些字段,或者通常自行转义并检查。

 

MyBatis框架作为一款半自动化的持久层框架,其SQL语句都要我们自己手动编写,这个时候当然需要防止SQL注入。其实,MyBatis的SQL是一个具有“输入+输出”的功能,类似于函数的结构,如下:

<select id="getBlogById" resultType="Blog" parameterType=”int”>
         SELECT id,title,author,content
         FROM blog
         WHERE id=#{id}
</select>

  这里,parameterType表示了输入的参数类型,resultType表示了输出的参数类型。回应上文,如果我们想防止SQL注入,理所当然地要在输入参数上下功夫。上面代码中黄色高亮即输入参数在SQL中拼接的部分,传入参数后,打印出执行的SQL语句,会看到SQL是这样的:

SELECT id,title,author,content FROM blog WHERE id = ?

  不管输入什么参数,打印出的SQL都是这样的。这是因为MyBatis启用了预编译功能,在SQL执行前,会先将上面的SQL发送给数据库进行编译;执行时,直接使用编译好的SQL,替换占位符“?”就可以了。因为SQL注入只能对编译过程起作用,所以这样的方式就很好地避免了SQL注入的问题。

  【底层实现原理】MyBatis是如何做到SQL预编译的呢?其实在框架底层,是JDBC中的PreparedStatement类在起作用,PreparedStatement是我们很熟悉的Statement的子类,它的对象包含了编译好的SQL语句。这种“准备好”的方式不仅能提高安全性,而且在多次执行同一个SQL时,能够提高效率。原因是SQL已编译好,再次执行时无需再编译。

 

  

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

【结论】

在编写MyBatis的映射语句时,尽量采用#{xxx}这样的格式。若不得不使用${xxx}这样的参数,要手工地做好过滤工作,来防止SQL注入攻击。

#{}:相当于JDBC中的PreparedStatement

${}:是输出变量的值

简单说,#{}是经过预编译的,是安全的${}是未经过预编译的,仅仅是取变量的值,是非安全的,存在SQL注入。

如果我们order by语句后用了${},那么不做任何处理的时候是存在SQL注入危险的。你说怎么防止,那我只能悲惨的告诉你,你得手动处理过滤一下输入的内容。如判断一下输入的参数的长度是否正常(注入语句一般很长)

 

 

原理介绍:

myBatis 对于#{} 在boundSql 的时候,会将sql  语句解析成为?;对于${} 则本来的值进行替换。

对于  select * from emp where name = #{employeeName},myBatis 会解析sql为:select * from emp where name = #{employeeName},然后进行prepareStatment 预编译处理。

对于 select * from emp where name = ${employeeName},myBatis 会解析sql为:select * from emp where name = 'employeeName',然后进行prepareStatment 预编译处理。

myBatis 其实底层防止sql注入,使用的是prepareStatment语句。表现为#{employeeName}和${employeeName}的两种参数注入方法。

 

 

 

 

参考:

http://blog.youkuaiyun.com/szwangdf/article/details/26714603

http://www.myexception.cn/sql/1938757.html

https://blog.youkuaiyun.com/u013417227/article/details/70597871

### MyBatis 中 `#` 和 `$` 符号的区别 #### 占位符功能差异 在 MyBatis 中,`#{}` 和 `${}` 都可以作为占位符来插入参数到 SQL 语句中。然而两者的工作机制存在显著不同。 当使用 `#{}` 形式的占位符时,MyBatis 将其视为预处理语句 (PreparedStatement) 的参数绑定方式[^1]。这意味着实际的 SQL 发送到数据库之前会先由 JDBC 进行一次转义处理,从而有效防止 SQL 注入攻击的发生。 而采用 `${}` 方式,则是直接替换模板中的变量名为其对应的值字符串,并不做任何额外的安全检查或转换操作[^2]。因此,在某些特殊情况下可能会引入潜在风险。 #### 使用场景对比 由于上述特性上的差别,这两种语法适用于不同的编程环境: - 对于大多数常规查询条件构建而言,推荐优先选用 `#{}` 结构以增强应用程序的整体安全性; - 当遇到一些无法通过标准 API 实现的需求——比如表名、列名动态指定等情况时,则可能不得不借助 `${}` 完成相应逻辑编码工作;不过此时应当格外谨慎对待输入验证环节[^3]。 #### 示例代码展示 下面给出一段简单的例子说明如何分别运用这两种表达形式编写 Mapper XML 文件内的 SELECT 语句: ```xml <!-- 正确做法 --> <select id="findUserById" parameterType="int" resultType="com.example.User"> SELECT * FROM users WHERE user_id = #{userId} </select> <!-- 错误示范:容易遭受注入威胁 --> <select id="findByTableName" parameterType="string" resultType="map"> SELECT * FROM ${tableName} <!-- 不建议这样写 --> </select> ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值