---

前言

软件漏洞可以对系统造成严重危害，如果被人恶意利用，会导致病毒感染、数据泄漏或损坏的风险，还可能面临直接或间接的经济损失。那么，我们应该如何预防这些漏洞呢？在深入探讨漏洞问题之前，首先需要明确什么是漏洞。

---

一、什么是漏洞？

漏洞是指软件、系统或网络中存在的安全弱点或错误，这些弱点可能导致系统遭受攻击或被不当使用。在计算机安全领域，漏洞通常源于编程错误、设计缺陷或配置失误。

对于对象关系映射（ORM）框架来说，漏洞通常指的是设计或实施中的安全问题，这些问题可能让应用程序面临SQL注入攻击的风险。

SQL 注入漏洞
如果ORM框架在执行SQL操作时没有正确过滤或转义用户输入，攻击者可以利用输入的恶意数据来执行未经授权的数据库操作，从而造成数据泄露、损坏或篡改。

什么情况下会引起 SQL 注入攻击呢？通常是在以下情况：

• 表结构部分：通常包含表字段、表名等固定内容。
• 表字段参数/变量部分：通过包含各种动态 SQL 参数。

通常 ORM 中 SQL 注入漏洞的发生都是因为以上两个部分允许从前台传参导致的。

二、如何预防漏洞

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

1.表字段部分

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

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

2.字段参数/变量部分

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

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

3. 使用工具类预防

一般来说，通过上面的处理就可以避免 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 片段。

---

总结

回到顶部

尽量避免前端传入 SQL 片段，对于前端传入的SQL片段通过手动校验的方式避免SQL注入。
常见问题章节也推荐大家去看一下，里面覆盖了很多众多业务场景的解决方案。