本文主要是介绍MyBatis-Plus 框架 QueryWrapper UpdateWrapper 方法修复sql注入漏洞事件，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
什么是漏洞？
漏洞是指软件、系统或网络中存在的安全弱点或错误，这些弱点可能导致系统遭受攻击或被不当使用。在计算机安全领域，漏洞通常源于编程错误、设计缺陷或配置失误。
对于对象关系映射（ORM）框架来说，漏洞通常指的是设计或实施中的安全问题，这些问题可能让应用程序面临SQL注入攻击的风险。
SQL 注入漏洞
如果ORM框架在执行SQL操作时没有正确过滤或转义用户输入，攻击者可以利用输入的恶意数据来执行未经授权的数据库操作，从而造成数据泄露、损坏或篡改。
什么情况下会引起 SQL 注入攻击呢？通常是在以下情况：
表结构部分：通常包含表字段、表名等固定内容。
表字段参数/变量部分：通过包含各种动态 SQL 参数。
通常 ORM 中 SQL 注入漏洞的发生都是因为以上两个部分允许从前台传参导致的。
如何预防漏洞
明白漏洞产生的主要原因，那么我们只需要控制好表结构、参数相关的数据，避免他们暴露到前端既可避免漏洞攻击。
表字段部分
对于表字段部分通常来说应该由后端控制，但有些系统为了保持足够大的灵活性，允许前端动态传入数据库字段名称。这种做法虽然满足了系统的灵活性要求，却面临着极大的 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，这样最安全。
关于恶意漏洞的说明
MyBatis-Plus 相关的代码和 Jar 包被别有用心的人提交了 CVE 漏洞，下面对这些漏洞进行一下官方的声明。
提醒！ 请您注意这种不被官方认可的 “CVE 漏洞” 对框架本身、对用户、对项目的交付都会产生非常大的影响，您的 损人不利己的行为 给别人带来非常大的经济损失。
如果是不安全的设计，最好的办法是 issue 或 pull request 协助官方尽快修复。
官方文档也 一而再 再而三 的强调 SQL 片段 必须检查安全，任何 ORM 框架，包括 JDBC 都是允许 字符串直接拼接SQL 的情况，因此，我们建议最好不要允许前端传入 SQL 片段。
CVE-2024-35548
详情链接：CVE-2024-35548
该“漏洞”也是前端端传入 SQL 片段 导致 SQL 注入攻击。框架 QueryWrapper UpdateWrapper 字段部分是允许子查询的因此不能人为允许前端传入 SQL 片段。
如果使用者有这种需求，可以使用 SqlInjectionUtils.check(内容) 或 xxWrapper.checkSqlInjection() 方法来检查，如果检查通过，则不会抛出异常。
框架也提供了非常严格的条件构造器 LambdaQueryWrapper LambdaUpdateWrapper 推荐使用。
CVE-2023-25330
详情链接：CVE-2023-25330
该“漏洞”描述了一个所谓的多租户插件引起的漏洞，说多租户插件会引起 SQL 注入攻击。让我们看看这是怎么操作的？
该“漏洞”提交者恶意暴露租户 ID 给前端，允许前端传入租户 ID，并保持在上下文中，在插件运行阶段直接读取并使用。
如果我们做过租户隔离相关的需求，就明白我们通常的做法都是用户登录了之后，后端自己查询用户所对应的租户，并自行保持上下文，保障多租户插件的正常运行。
即便要做切换租户的操作，前端传入的切换租户的 ID 也不可能说直接就拿给插件用了，而是要检测能不能切的。
如果硬要说是问题，那这也是由于使用的时候考虑不当引起的，作为一个底层框架是无法约束使用者到底怎么去使用这些功能，如果什么都需要底层框架去兜底，那人人都去当伸手党吧，别搞什么开源了。
CVE-2022-25517
详情链接：CVE-2022-25517，由于原漏洞仓库已经被删除，可以点此观看详情分析
该“漏洞”更加搞笑，把表字段作为前端可以传入的一部分直接拿去拼接，然后硬说这个是漏洞。理由是因为 MyBatis-Plus 开放了 String 类型的字段参数，就可以拿去传递 SQL 攻击脚本。
我们都知道 MyBatis-Plus 提供了 LamdbaQueryWrapper，可以用 LamdbaQueryWrapper 执行 Type-Safe 的查询，我们相信绝大多数人也是这样去使用的，即便用了普通的 QueryWrapper，有 String 类型的字段，也绝对不是前端传递给我们的，那字段都由前端来传，还要后端干啥？干脆让前端直接写 SQL 得了。
如果是真正的漏洞问题，我们一定积极修正，但是上面两个如此低级的错误，在没跟我们预先进行沟通的情况下，直接提交了 CVE 漏洞申请，很难让我们相信这些漏洞是好心人善意的提醒，在我们看来，这就是存粹的坏心思。
这篇关于MyBatis-Plus 框架 QueryWrapper UpdateWrapper 方法修复sql注入漏洞事件的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
