MyBatis-Plus CVE-2022-25517 SQL injection！！！

当前使用版本(必填,否则不予处理)

3.5.1

该问题是如何引起的？(确定最新版也有问题再提!!!)

MyBatis plus v3.4.3 was discovered to contain a SQL injection vulnerability via the Column parameter in /core/conditions/AbstractWrapper.java.

重现步骤(如果有就写完整)

https://github.com/HaHarden/mybatis-plus-sql-Injection

报错信息

Comment From: manulifeam-happymabel

hi @miemieYaho we found the same SQL injection vulnerability in the snyk scanning. much appreciated if you can help to fix it. many thanks!

Comment From: WangHao237

我们也在snyk中发现了同样的SQL注入漏洞，如下图。希望团队大大们能尽快修复它，非常感谢！！

Comment From: haohao6683

We met the same SQL injection vulnerability in the snyk scanning, much appreciated if you guys can help to fix it. many thanks!

Comment From: haohao6683

Or if there exist some workaround solution to fix it? Thanks!

Comment From: wzw1990

pageSort也有SQL注入漏洞

Comment From: VampireAchao

Maybe we need to figure it out ourselves

Comment From: D-ping

我们也遇到snyk这个报错，个人认为楼主的验证是有问题的，sql注入只对sql语句的编译过程有破坏作用，比如#{}参数化查询底层使用preparedstatement处理sql，而preparedstatement的sql语句编译阶段已经准备好了，执行阶段只是把输入串作为数据处理，而不再对sql语句进行解析、准备，因此也就避免了sql注入问题，你的注入点是column，你既然需要自定义column值作为查询条件，而动态表名,动态列名做参数那mybatis本身就没办法使用preparedstatement预编译sql，就比如你使用${}传参确实存在sql注入，但你不能说mybatis-plus存在sql注入bug吧?这种情况本身就需要自己去过滤sql注入。如果有哪些说的不对的地方请大佬们指正！如果确实不是bug还请及时关闭issue万分感谢！

Comment From: kellach

我们也遇到了类似的问题，希望官方能尽快修复

Comment From: JohnyLi

同 @D-ping 的意见，就跟batis的${}一样，如果输入来源不可信，那应该是由使用者自行进行过滤，而不是让框架解决。

Comment From: Deathef

这个地方应该是可以做安全加固的吧，column是列名，column本身就不合法的情况下，框架层面就不应该再进行SQL构造了吧

Comment From: alanland

我们也遇到snyk这个报错，个人认为楼主的验证是有问题的，sql注入只对sql语句的编译过程有破坏作用，比如#{}参数化查询底层使用preparedstatement处理sql，而preparedstatement的sql语句编译阶段已经准备好了，执行阶段只是把输入串作为数据处理，而不再对sql语句进行解析、准备，因此也就避免了sql注入问题，你的注入点是column，你既然需要自定义column值作为查询条件，而动态表名,动态列名做参数那mybatis本身就没办法使用preparedstatement预编译sql，就比如你使用${}传参确实存在sql注入，但你不能说mybatis-plus存在sql注入bug吧?这种情况本身就需要自己去过滤sql注入。如果有哪些说的不对的地方请大佬们指正！如果确实不是bug还请及时关闭issue万分感谢！

我没进行测试，但是如果像截图显示那样： 1. 我们把方法参数定义为 column，那么它是不是就应该像列名一样工作才对； 2. 如果列名不合法或者不存在，执行过程找不到对应的列数据，应该提示错误 1054 - Unknown column 'id=1) ...' in 'field list'； 3. 如果表中没有列 id=1 ...，返回了查询数据，那么是方法的问题； 4. 如果参数 column 设计成是可以作为 SQL 片段拼接的，而不是列名，最好是重构下参数名，比如叫：sqlSnippet 等

@JohnyLi 我觉得防 SQL 注入不就是用来处理输入信息不可信、不安全的嘛。不应该再由用户（程序终端用户或框架使用者）处理。如果所有数据的可信、安全、正确，也不会有注入问题了。

Comment From: qmdx

这是一个贻笑大方的 漏洞 https://mp.weixin.qq.com/s?__biz=MzA4NzgyMTI0MA==&mid=2649525899&idx=1&sn=6f6806f188dbf9b76b4268aa521a465d&chksm=882bb05cbf5c394ae6ce75543052af18ff47a9f4a08bec0a8280cd51d162b3acc4bc7ebd6d27&token=653148079&lang=zh_CN#rd

真是害人不浅啊，提交这个漏洞的人

Comment From: shengming007

page中的OrderItem的column字段有sql注入风险 user,user1,user2三张表 都有id,name 字段

page.addOrder(new OrderItem("name ;drop table user1;select * from user2 order by id ",true));

貌似可以删除掉user1表

Comment From: VampireAchao

可以使用：com.baomidou.mybatisplus.core.toolkit.sql.SqlInjectionUtils#check

Comment From: qmdx

page中的OrderItem的column字段有sql注入风险 user,user1,user2三张表 都有id,name 字段

page.addOrder(new OrderItem("name ;drop table user1;select * from user2 order by id ",true));

貌似可以删除掉user1表

你为什么非要前端传入 sql 而不做校验？？？

Comment From: Deathef

@qmdx 你难道不知道客户端的参数都是不可信的吗？为什么我一定要通过前端，我直接扫你的接口呢？

Comment From: qmdx

@qmdx 你难道不知道客户端的参数都是不可信的吗？为什么我一定要通过前端，我直接扫你的接口呢？

按照你这个标准允许输入字符串属于 sql 注入，那么 mybatis原生 jpa hibernate 都是存在注入的，另外你升级到高版本 mp 针对 order by 允许输入字符串部分做了 sql 的校验（之前没有限制那么严格也是想留有更多的操作空间）。

Comment From: VampireAchao

可以自己写一个过滤器进行处理，我们公司确实有前端传sql的需求，做flink实时计算，将客户传过来的sql去执行flink逻辑

使用：com.baomidou.mybatisplus.core.toolkit.sql.SqlInjectionUtils#check 可以轻松校验 参数 是否存在sql关键字

Comment From: SimonXianyu

感觉 开发团队对 sql 注入的认知不深。这样子 不敢用了。

Comment From: SimonXianyu

可以使用：com.baomidou.mybatisplus.core.toolkit.sql.SqlInjectionUtils#check

既然 有这个方法，完全可以加在上面提到的 方法里，比如对传入的column检查。

Comment From: VampireAchao

感觉 开发团队对 sql 注入的认知不深。这样子 不敢用了。

sql注入——维基百科

感谢 您的反馈，我们会努力将mybatis-plus做的越来越好，希望能在将来的某一天得到先生您的认可

Comment From: qmdx

感觉 开发团队对 sql 注入的认知不深。这样子 不敢用了。

请让 mybatis $ 占位符去掉 ，jpa 也不允许拼接字符串 ，不要把自己的无知加在别人头上

Comment From: 404-error-404

所以大伙们，有个解决方案吗？这会好纠结

Comment From: nancheung

所以大伙们，有个解决方案吗？这会好纠结

本来就不是漏洞，不需要解决哇

Comment From: 404-error-404

所以大伙们，有个解决方案吗？这会好纠结

本来就不是漏洞，不需要解决哇

那建议看看这个CVE能不能申请关掉 idea 2022.2.3，会报警告

Comment From: SimonXianyu

感觉 开发团队对 sql 注入的认知不深。这样子 不敢用了。

请让 mybatis $ 占位符去掉 ，jpa 也不允许拼接字符串 ，不要把自己的无知加在别人头上

如果 是我无知，那么请去 CVE 申请关掉这个漏洞呗，你能 在那边申请关掉才能说明你不无知。

Comment From: whcrow

感觉 开发团队对 sql 注入的认知不深。这样子 不敢用了。

请让 mybatis $ 占位符去掉 ，jpa 也不允许拼接字符串 ，不要把自己的无知加在别人头上

如果 是我无知，那么请去 CVE 申请关掉这个漏洞呗，你能 在那边申请关掉才能说明你不无知。

不敢用？爱用不用，不用拉几把倒，优秀的开源软件不需要你等阴阳怪气的人来定论

Comment From: Deathef

所以大伙们，有个解决方案吗？这会好纠结

@qmdx 本质上是列注入的问题，其实完全可以像 @alanland 说的那样，在Wrapper构建column的时候增加检测，非法的列就应该抛出异常。

Comment From: qmdx

感觉 开发团队对 sql 注入的认知不深。这样子 不敢用了。

请让 mybatis $ 占位符去掉 ，jpa 也不允许拼接字符串 ，不要把自己的无知加在别人头上

如果 是我无知，那么请去 CVE 申请关掉这个漏洞呗，你能 在那边申请关掉才能说明你不无知。

你在去找下提交漏洞的问题仓库，都被提交者自己删除了（ 关于 CVE 也去找过官方，它根本没有沟通渠道，单方面定性为漏洞 ），MP 本身提供 2 种 机制 ，如果你觉得可以强制约束字段，禁止前端传入，你可以使用 lambda wrapper

@Deathef

Comment From: Deathef

@qmdx 我知道怎么避免这种所谓的注入，在哪做都很简单，没什么复杂的。我是觉得哪怕不是漏洞，多做一层安全加固也没什么问题吧，作为框架，更安全不是更好吗。如果MP的运营模式不支持修改的话，不改也没啥问题的。

Comment From: qmdx

@qmdx 我知道怎么避免这种所谓的注入，在哪做都很简单，没什么复杂的。我是觉得哪怕不是漏洞，多做一层安全加固也没什么问题吧，作为框架，更安全不是更好吗。如果MP的运营模式不支持修改的话，不改也没啥问题的。

前端可以任意传入的地方都是需要校验的 MP 内部也提供了校验工具类 com.baomidou.mybatisplus.core.toolkit.sql.SqlInjectionUtils#check ，更多的还是需要开发者自己主动的去注意这个问题，大家不去批评 JPA mybatis 甚至 JDBC 都是可以拼接 SQL 执行，而是来批评 MP 其实是不合理的 。

Comment From: SimonXianyu

网页 https://cveform.mitre.org/ 里面选 Action Request an update to an existing CVE Entry

然后可以提交新的描述