问题：Druid SQL注入校验为何拦截`SELECT 1=1`？

Question

**Druid SQL注入校验为何拦截`SELECT 1=1`？** 在使用阿里巴巴的数据库连接池Druid时，其内置的SQL防火墙（WallFilter）会对SQL语句进行SQL注入风险检测。当执行类似`SELECT 1=1`这样的语句时，Druid可能会将其拦截并报出安全风险警告。 原因是`1=1`是常见的SQL注入攻击中用于恒成立判断的表达式，攻击者常利用其绕过条件限制，例如拼接为`OR 1=1`以绕过查询条件获取全部数据。Druid出于安全考虑，默认将包含该表达式的SQL标记为潜在注入风险。 虽然`SELECT 1=1`本身并无危害，但在字符串拼接SQL的场景下可能被恶意利用。因此Druid默认策略较为保守，建议开发者使用预编译参数化查询来避免误判，同时提升系统安全性。

Answer 1

1. 问题现象：Druid为何拦截`SELECT 1=1`？

在使用阿里巴巴开源的数据库连接池组件Druid时，如果启用了其内置的SQL防火墙（WallFilter），当执行类似如下SQL语句：

SELECT 1=1;

可能会被Druid拦截并抛出类似如下的警告或异常信息：

WallFilter: com.alibaba.druid.wall.spi.WallVisitorUtils - sql not allow : SELECT 1=1

从表象来看，这条SQL语句本身并没有任何实际危害，甚至在某些测试场景中是合法且常见的用法。那么为什么会被Druid视为潜在风险呢？

2. 原理剖析：SQL注入检测机制与关键字识别

Druid的WallFilter模块用于防止SQL注入攻击，它通过预设规则对传入的SQL进行语法树解析和关键词匹配。

其中，`1=1`是一个经典的SQL注入标志词。攻击者常利用其构造恒为真的条件绕过业务逻辑判断，例如：

SELECT * FROM users WHERE username = 'admin' OR 1=1 --

上述语句将绕过原本的username验证，获取全部用户数据。

因此，Druid出于安全考虑，默认将包含`1=1`的SQL语句标记为潜在风险，并予以拦截。

3. 深度分析：为何简单的`SELECT 1=1`也会被拦截？

虽然`SELECT 1=1`本身并无恶意意图，但在以下几种情况下仍可能被滥用：

• 动态拼接SQL字符串时，若用户输入未加过滤，可能导致恶意代码注入；
• 部分框架或代码库内部处理不当，可能将该语句作为模板拼接到其他查询中；
• 攻击者可通过模糊变体（如`1 LIKE 1`、`1<2`等）尝试绕过检测。

Druid默认采用“保守策略”，即只要出现敏感模式就拦截，以最大限度保障系统安全。

4. 解决方案与规避方法

开发者可以采取以下几种方式来避免误判或提升安全性：

方法	说明
使用参数化查询	替代字符串拼接，从根本上杜绝SQL注入风险
关闭WallFilter	适用于信任所有SQL来源的环境（不推荐）
自定义白名单规则	允许特定SQL通过，但需谨慎配置

5. 示例流程图：Druid SQL校验过程

graph TD
        A[SQL请求进入] --> B{是否启用WallFilter?}
        B -->|否| C[直接放行]
        B -->|是| D[解析SQL语法树]
        D --> E{是否匹配注入规则?}
        E -->|是| F[拦截并记录日志]
        E -->|否| G[正常执行SQL]

6. 建议与最佳实践

为了兼顾安全性与灵活性，建议采取如下措施：

• 始终使用PreparedStatement进行数据库操作；
• 避免手动拼接SQL语句；
• 对用户输入进行严格校验和过滤；
• 如确有需要执行`SELECT 1=1`，可临时关闭WallFilter或添加自定义规则。