SQL写在XML文件，如何做安全性上的防范性

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，这样最安全。