安全漏洞避免说明
提示
如何编写安全的代码，什么是漏洞？
常见漏洞
软件编写存在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("任意前端传入字段")
2
3
4
5
6
# 被恶意认定为漏洞的说明
吐槽一下！ 真正的漏洞我们是很虚心的改正，但是这些如此低级的错误，还好意思发到网上？
您这不是编码能力有限，那就是坏。
- 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 避免动态字符串。