提示

如何编写安全的代码，什么是漏洞？

常见漏洞 软件编写存在bug 设计存在缺陷 探讨这个问题前我们来先定义 ORM 框架的漏洞，作为 ORM 框架它的职责是负责执行 SQL 操作数据， 那么 SQL注入 就是主要漏洞点，什么情况下会引起SQL注入呢？也就是执行SQL参数脱离预编译允许拼接 SQL片段 的时候。

• 表字段部分

对于固定字段部分，有些系统为了灵活使用动态字段，这种情况需要系统设计者开发人员自己控制保证字段的安全性， 绝对不能允许 前端任意传入 字符串拼接，如果有这种需求也是需要有字段映射判断逻辑的。

• 字段变量部分

这部分通常ORM框架都是有做 预编译防止SQL注入 逻辑处理，如果存在 允许恶意拼接SQL 我们可以认定为 SQL注入漏洞 通常 框架也会明确告知风险，比如 MyBatis 占位符 $ 是存在注入风险的 使用者需要自行控制安全，尽量使用 占位符 # 规避风险。

防止 SQL 注入

使用 MP 提供的工具类 SqlInjectionUtils.check(内容) 验证字符串是否存在 SQL 注入 存在抛出异常， 注意！！最好是不允许任何 SQL片段 由前端传到后台，如果你要嘴硬那么请您直接让前端操作数据库，不要使用任何 ORM 框架！！

• SQL 注入安全保护说明

Wrappers.query()
// 开启自动检查 SQL 注入 (3.5.3.2+ 版本支持，强烈建议前端不能传入SQL片段，无法避免必须验证合法性)
.checkSqlInjection().orderByDesc("任意前端传入字段")
​
// 手动校验方式
SqlInjectionUtils.check("任意前端传入字段")

被恶意认定为漏洞的说明

吐槽一下！ 真正的漏洞我们是很虚心的改正，但是这些如此低级的错误，还好意思发到网上？

您这不是编码能力有限，那就是坏。

• MybatisPlus <= 3.5.3.1 TenantPlugin 租户组件 存在 sql 注入漏洞

CVE-2023-25330 (opens new window)

该“漏洞”提交者恶意暴露 表字段部分 使前端可任意传入，硬要说是漏洞也是 软件编写存在bug 底层框架是无法约束 使用者传入什么字段的，这种情况 软件开发者 需要做映射字段逻辑判断。

• SQL 注入漏洞 CVE-2022-25517

CVE-2022-25517 (opens new window)

原漏洞仓库已经被删除，点击详情分析 (opens new window)

该“漏洞”利用 QueryWrapper 允许字符串传入 字段名 人为注入 SQL片段 也是犯了上面一样的错误，属于 软件编写存在bug 我们可以使用 LambdaQueryWrapper 避免动态字符串。