SQL注入拦截实战：从“sql injection violation”报错到MyBatis/Druid安全配置

1. 当"sql injection violation"突然出现时

第一次在日志里看到"java.sql.SQLException: sql injection violation, dbType mysql"这个报错，很多开发者都会心头一紧。这个错误通常出现在集成测试阶段或者线上环境，就像你正在平稳行驶的汽车突然亮起了发动机故障灯。我遇到过最典型的情况是：一个运行了半年的查询接口突然开始报这个错误，而开发团队坚称"我们什么都没改"。

实际上，这类报错往往意味着你的SQL语句触发了数据库安全组件的防护机制。常见的触发点包括：

• MyBatis中使用了危险的${}字符串拼接
• Druid连接池的WallFilter检测到可疑语法
• 字段名与SQL关键字冲突导致语法歧义
• 分库分表中间件（如Sharding-JDBC）的严格校验

最近处理的一个案例特别典型：某电商平台的订单查询接口突然大面积报错，最终发现是因为有人用"order"作为查询参数值，而这个单词恰好是SQL关键字。数据库安全组件将其判定为潜在的SQL注入攻击，于是果断拦截。

2. 快速定位问题SQL的四种方法

遇到这类报错时，最重要的是先找到触发拦截的具体SQL语句。根据我的经验，这四个方法最有效：

2.1 查看完整错误堆栈

很多开发者只看错误的第一行，其实完整的堆栈信息可能包含更多线索。比如：

java复制com.alibaba.druid.wall.WallFilter.checkInternal(WallFilter.java:742)
com.alibaba.druid.wall.WallFilter.check(WallFilter.java:541)

这样的堆栈明确告诉我们，是Druid的WallFilter在起作用。

2.2 开启SQL日志

对于MyBatis项目，可以在配置文件中开启SQL日志：

yaml复制mybatis:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这样控制台会打印出实际执行的SQL语句，方便你检查是否有可疑的拼接操作。

2.3 使用Druid的监控页面

如果项目使用了Druid连接池，访问内置的监控页面（通常位于/druid/index.html）可以看到最近执行的SQL语句和拦截记录。我曾经在这里发现过一个定时任务每月1号执行的统计SQL被误判为注入攻击。

2.4 数据库层面的查询日志

对于MySQL数据库，可以临时开启通用查询日志：

sql复制SET GLOBAL general_log = 'ON';
SET GLOBAL log_output = 'TABLE';

然后通过查询mysql.general_log表查看所有执行过的SQL语句。记得用完后关闭日志以避免性能影响。

3. MyBatis的安全使用实践

MyBatis作为最常用的ORM框架之一，其SQL注入防护主要依赖于正确的参数传递方式。我见过太多因为混淆#{}和${}用法导致的注入拦截问题。

3.1 #{}和${}的本质区别

这两个符号看起来相似，但安全性天差地别：

xml复制<!-- 安全写法（参数化查询） -->
<select id="getUser" resultType="User">
  SELECT * FROM user WHERE id = #{userId}
</select>

<!-- 危险写法（字符串拼接） -->
<select id="getUser" resultType="User">
  SELECT * FROM user WHERE id = ${userId}
</select>

#{}会被编译为预编译语句的参数占位符（?），而${}则是直接文本替换。后者相当于打开了SQL注入的大门。

3.2 必须使用${}的场景与防护

有些场景确实需要${}，比如动态表名：

xml复制<select id="getOrderByMonth" resultType="Order">
  SELECT * FROM order_${month}
</select>

对于这种情况，我的建议是：

1. 建立严格的白名单机制
2. 在Java代码层面对输入进行校验
3. 使用正则表达式确保只包含合法字符

java复制// 白名单校验示例
public void validateTableName(String tableName) {
    if (!tableName.matches("^[a-zA-Z0-9_]+$")) {
        throw new IllegalArgumentException("非法表名");
    }
}

3.3 MyBatis-Plus的特殊注意事项

MyBatis-Plus的Wrapper构建器也可能产生注入风险。比如：

java复制// 不安全的写法
QueryWrapper<User> wrapper = new QueryWrapper<>();
wrapper.eq("name", request.getParameter("name"));

更安全的做法是使用Lambda表达式：

java复制LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(User::getName, request.getParameter("name"));

Lambda方式在编译时就会检查字段名的合法性，避免了字符串拼接的风险。

4. Druid安全配置深度解析

Druid作为阿里开源的数据库连接池，其内置的WallFilter提供了强大的SQL注入防护能力，但配置不当也可能导致误伤。

4.1 WallFilter的工作原理

WallFilter会分析SQL语句的语法结构，检测以下风险：

• 永真条件（如1=1）
• 可疑函数调用（如sleep()、benchmark()）
• 多条语句执行（如SELECT...; DROP...）
• 注释语法滥用（如/!50000SELECT/）

4.2 精确配置WallFilter

这是我在生产环境中验证过的安全配置：

properties复制# 基础配置
druid.wall.enable=true
druid.wall.mysql.enable=true

# 高危操作拦截
druid.wall.config.delete-allow=false
druid.wall.config.drop-table-allow=false
druid.wall.config.alter-table-allow=false

# 允许必要的操作
druid.wall.config.select-all-column-allow=true
druid.wall.config.multi-statement-allow=false

# 白名单配置
druid.wall.config.variant-check=true
druid.wall.config.metadata-allow=true

4.3 处理误报的三种策略

当合法SQL被误判为注入时，可以：

1. 调整WallFilter的检测规则（谨慎使用）
2. 将合法SQL加入白名单
3. 重构SQL避免触发规则

我曾经遇到一个报表查询因为使用复杂的CASE WHEN语句被拦截，最终通过将整个SQL加入白名单解决：

properties复制druid.wall.config.select-allow=SELECT ...(完整SQL)

5. 分库分表场景下的特殊处理

Sharding-JDBC等分库分表中间件对SQL有更严格的校验要求，这也是注入拦截的高发区。

5.1 分片键必须出现在WHERE中

这是最常见的错误之一：

sql复制-- 错误写法（缺少分片键）
SELECT * FROM order WHERE status = 'PAID'

-- 正确写法
SELECT * FROM order WHERE user_id = 123 AND status = 'PAID'

如果user_id是分片键，它必须出现在查询条件中。

5.2 动态排序的安全实现

对于前端传入的排序字段，必须做白名单校验：

java复制// 安全校验示例
private String validateSortField(String field) {
    Set<String> allowedFields = Set.of("create_time", "price", "quantity");
    if (!allowedFields.contains(field)) {
        return "create_time"; // 默认值
    }
    return field;
}

5.3 分页查询的陷阱

分页查询时，避免直接拼接limit参数：

sql复制-- 危险写法
SELECT * FROM order LIMIT ${start}, ${size}

-- 安全写法
SELECT * FROM order LIMIT ?, ?

参数应该通过PreparedStatement设置，而不是直接拼接。

6. 从根源预防SQL注入

与其事后处理报错，不如从设计阶段就预防问题。我在项目评审时总会强调这些点：

6.1 数据库设计规范

• 避免使用SQL关键字作为字段名（如order、desc、group等）
• 字段名采用下划线命名法（如user_name）
• 为表名添加前缀（如t_order、t_user）

6.2 开发约束

• 代码审查时重点关注SQL拼接
• 在IDE中安装SQL注入检测插件
• 定期扫描代码中的${}使用情况

6.3 测试策略

• 在单元测试中加入SQL注入测试用例
• 使用OWASP ZAP等工具进行安全扫描
• 对生产环境的SQL日志进行定期审计

记得有一次代码审查，我发现一个新人开发写了这样的代码：

java复制String sql = "SELECT * FROM user WHERE name LIKE '%" + name + "%'";

当即要求他重写为参数化查询，并解释了其中的风险。三个月后公司安全扫描时，这个接口顺利通过了所有注入测试，那位开发者也养成了安全编码的习惯。

SQL注入防护不是一次性工作，而是需要持续关注的系统工程。每次看到"sql injection violation"报错，都应该把它当作改进系统安全性的机会，而不是简单的错误修复。