救命，求修复SQL注入安全漏洞，更新一版3.5.7 about mybatis-plus HOT 23 CLOSED

mybatis-plus 中的 wrapper 不是面向用户的，就像 jdbc 一样，完全信任程序员。一般情况下，用户都不应该能直接与 wrapper 存在交互。

我们不会也没有办法来纠正程序员本身的行为造成的错误！在基础设施层增加不必要的校验会有各种问题出现，自由度也会降低。

from mybatis-plus.

其实官方把方法的名字改了不就好了。 比如ruby方法名字加个！ 那样，名字加一个admin(AdminUpdate)之类.

为啥不想着更好的方法呢？ 类似的方法本来就极为容易混淆。 不想着改进。天天强调我没错，我没有bug，我没有cve。有意义吗？

1+1=2也要人提醒?

from mybatis-plus.

CVE权威受到我的质疑了

SpringBoot引入的snakeyaml包也有类似的恶意CVE，被开发者直接挂在主页怼：https://github.com/snakeyaml/snakeyaml

两码事，snakeyaml包那个CVE是纯后端故意改，外部不可能改的，所以才被挂上去。这个不一样，可以从前端注入的。不要说什么程序员低级之类的话，很多知名后端知名admin都中过奖，比如JeecgBoot，被开过很多这种SQL注入CVE，较真的讲，都是MybatisPlus的Wrapper没做安全性检查，只不过没甩锅到MyBatisPlus这边罢了。对很多很早用MyBatisPlus的项目来讲，特别是MyBatisPlus还没有引入LambdaWrapper的时候，是有很多历史包袱再里面，为开发方便Request参数直接传进Wrapper很常见的。不要指望程序员有怎么高的安全意识，1+1=2也要人提醒之类的，要不然也不会有Log4j的惊天大漏洞。

那你意思是为了小水坑放弃一片大海是吧?有LambdaWrapper只是为了省事又不是为了强字段,你没用过eq("函数(字段)","值")不代表不存在

不是小水坑，是大水坑。这种开发其实并不少见。 很多大型企业都是有购买安全服务，其中就包含CVE检查，虽然很少有细到工具包，但是影响大的CVE还是有的，比如log4j的那个漏洞。MybatisPlus虽然是mybatis增强工具中起的最早最有名气的一个，但也不是不可替换的。如果因为这个问题而失去大批企业市场值得吗？真的要甩锅程序员低级，也应该默认把这个功能给关掉，而不是在文档豆腐大的地方加个提醒就完事的。

屁股决定脑袋，看你这回复就是被所谓的大企业领导催的不行了，唯招标论，无非是想绑架社区快点出包升级而已，不然不好交差。

from mybatis-plus.

MybatisPlus 最新漏洞 CVE-2024-35548 申明

预防安全漏洞

from mybatis-plus.

CVE权威受到我的质疑了

from mybatis-plus.

CVE权威受到我的质疑了

SpringBoot引入的snakeyaml包也有类似的恶意CVE，被开发者直接挂在主页怼：https://github.com/snakeyaml/snakeyaml

两码事，snakeyaml包那个CVE是纯后端故意改，外部不可能改的，所以才被挂上去。这个不一样，可以从前端注入的。不要说什么程序员低级之类的话，很多知名后端知名admin都中过奖，比如JeecgBoot，被开过很多这种SQL注入CVE，较真的讲，都是MybatisPlus的Wrapper没做安全性检查，只不过没甩锅到MyBatisPlus这边罢了。对很多很早用MyBatisPlus的项目来讲，特别是MyBatisPlus还没有引入LambdaWrapper的时候，是有很多历史包袱再里面，为开发方便Request参数直接传进Wrapper很常见的。不要指望程序员有怎么高的安全意识，1+1=2也要人提醒之类的，要不然也不会有Log4j的惊天大漏洞。

from mybatis-plus.

from mybatis-plus.

CVE权威受到我的质疑了

SpringBoot引入的snakeyaml包也有类似的恶意CVE，被开发者直接挂在主页怼：https://github.com/snakeyaml/snakeyaml

两码事，snakeyaml包那个CVE是纯后端故意改，外部不可能改的，所以才被挂上去。这个不一样，可以从前端注入的。不要说什么程序员低级之类的话，很多知名后端知名admin都中过奖，比如JeecgBoot，被开过很多这种SQL注入CVE，较真的讲，都是MybatisPlus的Wrapper没做安全性检查，只不过没甩锅到MyBatisPlus这边罢了。对很多很早用MyBatisPlus的项目来讲，特别是MyBatisPlus还没有引入LambdaWrapper的时候，是有很多历史包袱再里面，为开发方便Request参数直接传进Wrapper很常见的。不要指望程序员有怎么高的安全意识，1+1=2也要人提醒之类的，要不然也不会有Log4j的惊天大漏洞。

那你意思是为了小水坑放弃一片大海是吧?有LambdaWrapper只是为了省事又不是为了强字段,你没用过eq("函数(字段)","值")不代表不存在

from mybatis-plus.

其实官方把方法的名字改了不就好了。
比如ruby方法名字加个！ 那样，名字加一个admin(AdminUpdate)之类.

为啥不想着更好的方法呢？
类似的方法本来就极为容易混淆。
不想着改进。天天强调我没错，我没有bug，我没有cve。有意义吗？

from mybatis-plus.

CVE权威受到我的质疑了

SpringBoot引入的snakeyaml包也有类似的恶意CVE，被开发者直接挂在主页怼：https://github.com/snakeyaml/snakeyaml

from mybatis-plus.

CVE权威受到我的质疑了

SpringBoot引入的snakeyaml包也有类似的恶意CVE，被开发者直接挂在主页怼：https://github.com/snakeyaml/snakeyaml

两码事，snakeyaml包那个CVE是纯后端故意改，外部不可能改的，所以才被挂上去。这个不一样，可以从前端注入的。不要说什么程序员低级之类的话，很多知名后端知名admin都中过奖，比如JeecgBoot，被开过很多这种SQL注入CVE，较真的讲，都是MybatisPlus的Wrapper没做安全性检查，只不过没甩锅到MyBatisPlus这边罢了。对很多很早用MyBatisPlus的项目来讲，特别是MyBatisPlus还没有引入LambdaWrapper的时候，是有很多历史包袱再里面，为开发方便Request参数直接传进Wrapper很常见的。不要指望程序员有怎么高的安全意识，1+1=2也要人提醒之类的，要不然也不会有Log4j的惊天大漏洞。

那你意思是为了小水坑放弃一片大海是吧?有LambdaWrapper只是为了省事又不是为了强字段,你没用过eq("函数(字段)","值")不代表不存在

不是小水坑，是大水坑。这种开发其实并不少见。
很多大型企业都是有购买安全服务，其中就包含CVE检查，虽然很少有细到工具包，但是影响大的CVE还是有的，比如log4j的那个漏洞。MybatisPlus虽然是mybatis增强工具中起的最早最有名气的一个，但也不是不可替换的。如果因为这个问题而失去大批企业市场值得吗？真的要甩锅程序员低级，也应该默认把这个功能给关掉，而不是在文档豆腐大的地方加个提醒就完事的。

from mybatis-plus.

CVE权威受到我的质疑了

SpringBoot引入的snakeyaml包也有类似的恶意CVE，被开发者直接挂在主页怼：https://github.com/snakeyaml/snakeyaml

两码事，snakeyaml包那个CVE是纯后端故意改，外部不可能改的，所以才被挂上去。这个不一样，可以从前端注入的。不要说什么程序员低级之类的话，很多知名后端知名admin都中过奖，比如JeecgBoot，被开过很多这种SQL注入CVE，较真的讲，都是MybatisPlus的Wrapper没做安全性检查，只不过没甩锅到MyBatisPlus这边罢了。对很多很早用MyBatisPlus的项目来讲，特别是MyBatisPlus还没有引入LambdaWrapper的时候，是有很多历史包袱再里面，为开发方便Request参数直接传进Wrapper很常见的。不要指望程序员有怎么高的安全意识，1+1=2也要人提醒之类的，要不然也不会有Log4j的惊天大漏洞。

那你意思是为了小水坑放弃一片大海是吧?有LambdaWrapper只是为了省事又不是为了强字段,你没用过eq("函数(字段)","值")不代表不存在

不是小水坑，是大水坑。这种开发其实并不少见。 很多大型企业都是有购买安全服务，其中就包含CVE检查，虽然很少有细到工具包，但是影响大的CVE还是有的，比如log4j的那个漏洞。MybatisPlus虽然是mybatis增强工具中起的最早最有名气的一个，但也不是不可替换的。如果因为这个问题而失去大批企业市场值得吗？真的要甩锅程序员低级，也应该默认把这个功能给关掉，而不是在文档豆腐大的地方加个提醒就完事的。

真想搞事那mybatis增强工具没一个跑得掉,全都得有cve,只要有拼sql的功能那就都是隐藏的cve

from mybatis-plus.

真想搞事那mybatis增强工具没一个跑得掉,全都得有cve,只要有拼sql的功能那就都是隐藏的cve

的确，谁让MP是最知名和用户最多的呢，被盯上是必然的。说回漏洞本身，官方的回答属于站在上帝视角看问题了，官方认为用户知道，所以MP没加，用户也的确知道，同时也认为MP知道，其实MP不知道，漏洞就产生了。其实很多用MP的项目已经吃过这个漏洞的CVE了，只不过都没甩锅到MP头上罢了。

from mybatis-plus.

真想搞事那mybatis增强工具没一个跑得掉,全都得有cve,只要有拼sql的功能那就都是隐藏的cve

另外说一句，特地去看了下前段时间对MP贴脸开大的某MF框架，是有对column做安全检查的哦

from mybatis-plus.

MP也做了检查：
https://baomidou.com/reference/about-cve/

如何预防漏洞
明白漏洞产生的主要原因，那么我们只需要控制好表结构、参数相关的数据，避免他们暴露到前端既可避免漏洞攻击。

表字段部分
对于表字段部分通常来说应该由后端控制，但有些系统为了保持足够大的灵活性，允许前端动态传入数据库字段名称。这种做法虽然满足了系统的灵活性要求，却面临着极大的 SQL 注入风险。

如果想要规避风险，就必须要求系统设计者或开发人员自行控制字段的安全性，绝对不能让前端任意传入字符串直接转换为 SQL 字段，应通过字段映射逻辑来阻断攻击，避免前端接口传入的字段内容直接进入 SQL 编译阶段中生成最终 SQL。

字段参数/变量部分
对于字段参数部分，ORM 框架通常有做预编译防止 SQL 注入攻击的逻辑，在 MyBatis 中，通过使用 # 占位符，而不是 $ 占位符来避免 SQL 注入攻击。

MyBatis-Plus 在生成相关的 SQL 时底层能力同样来自 MyBatis，所以一样的可以是用 # 占位符来避免攻击，只不过这一个步骤由 MyBatis-Plus 自动完成了。

使用工具类预防
一般来说，通过上面的处理就可以避免 SQL 注入攻击了，如果您还不放心，可以使用 MyBatis-Plus 提供的工具类

SqlInjectionUtils.check(内容) 来验证字符串是否存在 SQL 注入，如果存在则会抛出对应的异常，

// 开启自动检查 SQL 注入 (3.5.3.2+ 版本支持
Wrappers.query().checkSqlInjection().orderByDesc("任意前端传入字段")
​
// 手动校验方式 (3.4.3.2+ 版本支持)
SqlInjectionUtils.check("任意前端传入字段")

注意

最好的预防方式仍旧是不允许任何SQL片段由前端传到后台，我们强烈建议不要开放给前端太多的动态 SQL，这样最安全。

from mybatis-plus.

真想搞事那mybatis增强工具没一个跑得掉,全都得有cve,只要有拼sql的功能那就都是隐藏的cve

另外说一句，特地去看了下前段时间对MP贴脸开大的某MF框架，是有对column做安全检查的哦

你是指这种安全检查吗?

from mybatis-plus.

真想搞事那mybatis增强工具没一个跑得掉,全都得有cve,只要有拼sql的功能那就都是隐藏的cve

另外说一句，特地去看了下前段时间对MP贴脸开大的某MF框架，是有对column做安全检查的哦

你是指这种安全检查吗?

的确，如果用MP兼容写法的话，对方一样有问题，你也可以提交下CVE了。我也很好奇对方对同一CVE的应对方式，会不会一样写小作文:)

from mybatis-plus.

真想搞事那mybatis增强工具没一个跑得掉,全都得有cve,只要有拼sql的功能那就都是隐藏的cve

另外说一句，特地去看了下前段时间对MP贴脸开大的某MF框架，是有对column做安全检查的哦

你是指这种安全检查吗?

的确，如果用MP兼容写法的话，对方一样有问题，你也可以提交下CVE了。我也很好奇对方对同一CVE的应对方式，会不会一样写小作文:)

为什么你要我去提cve?我像会干这破事的人吗?而且我也说了只要有拼sql的功能那就都是隐藏的cve

from mybatis-plus.

小刀有切JJ功能，但并不建议你使用呀。你要挥刀自宫，完又把责任推到小刀身上，小刀多冤！

from mybatis-plus.

其实我觉得可以加个InnerInterceptor，全局拦截进行sql注入检查，这样就不用在代码中每次都加checkSqlInjection了

from mybatis-plus.

建议重载相关函数，然后给这些重载函数添加一个参数来控制是否允许任意sql执行，老函数就默认不支持任意sql执行了；
或者干脆新增一批函数，新增函数支持任意sql执行，老函数默认不支持；
或者默认情况下老函数不支持任意sql执行，要执行任意sql时再手动设置。

老放着cve也不是一个事，弄得很多人在新项目都不敢用mp了，包括我自己。

from mybatis-plus.

建议重载相关函数，然后给这些重载函数添加一个参数来控制是否允许任意sql执行，老函数就默认不支持任意sql执行了； 或者干脆新增一批函数，新增函数支持任意sql执行，老函数默认不支持； 或者默认情况下老函数不支持任意sql执行，要执行任意sql时再手动设置。

老放着cve也不是一个事，弄得很多人在新项目都不敢用mp了，包括我自己。

争议cve,又不是定性的严重CVE，对项目有个毛线影响。官方态度也很明确了，我负责优雅美丽，你负责安全检查。不然也不会在打了补丁的情况下这么久不发布3.5.7了。MP的QueryWrapper作为所有国产ORM的老祖宗，是不可能有漏洞的，不然一条绳上的蚂蚱全部BBQ。自己项目做好安全检查吧。

from mybatis-plus.

建议重载相关函数，然后给这些重载函数添加一个参数来控制是否允许任意sql执行，老函数就默认不支持任意sql执行了； 或者干脆新增一批函数，新增函数支持任意sql执行，老函数默认不支持； 或者默认情况下老函数不支持任意sql执行，要执行任意sql时再手动设置。
老放着cve也不是一个事，弄得很多人在新项目都不敢用mp了，包括我自己。

争议cve,又不是定性的严重CVE，对项目有个毛线影响。官方态度也很明确了，我负责优雅美丽，你负责安全检查。不然也不会在打了补丁的情况下这么久不发布3.5.7了。MP的QueryWrapper作为所有国产ORM的老祖宗，是不可能有漏洞的，不然一条绳上的蚂蚱全部BBQ。自己项目做好安全检查吧。

有的客户安全团队会扫描jar包，有漏洞的话版本验收不了，即使去解释客户不一定认，认了也是浪费彼此的时间，这是站在个人立场的问题，跟我一样困惑的人肯定有不少。站在开源项目的立场，我也理解他们坚守的是什么，虽然了解事实的人都觉得这不是漏洞，无需改变，但是能不能稍微调整一下，在不影响原有功能的情况下，来避开这个所谓的“漏洞”呢，毕竟确实给很多mp使用者带来了很多困扰和心理负担。

from mybatis-plus.