防止SQL注入的数据库连接池SQL校验拦截器，本质上就是在应用程序获取数据库连接的那一刻，对即将执行的SQL语句进行语法和语义层面的安全扫描，把恶意注入代码挡在数据库执行层之前。传统的做法是在业务代码里用参数化查询来防注入，但这种方式依赖开发者的自觉和编码规范，一旦有人写了拼接SQL的代码，漏洞就出现了。而连接池层面的拦截器，是在更底层、更统一的位置做防护，不管谁写的SQL、不管哪个模块调用的，只要经过连接池拿到连接，就必须过一遍校验，这才是真正意义上的"兜底"方案。
为什么要在连接池层面做SQL校验？
很多团队觉得用了MyBatis、JPA这些ORM框架就安全了，其实不然。框架虽然支持参数化查询，但开发者依然可以通过字符串拼接的方式绕过框架的保护机制，直接写原生SQL。尤其是在一些复杂的动态查询场景、报表系统、多租户数据隔离场景中，拼接SQL几乎是不可避免的。这时候，如果在连接池层面加一道拦截，就能从根本上堵住这个口子。连接池是所有数据库操作的必经之路，不管你用什么方式访问数据库，最终都要从连接池拿连接，所以在这个位置做拦截，覆盖面最广、防护最彻底。
连接池SQL校验拦截器的核心工作原理
整个拦截器的工作流程可以拆解为四个步骤：第一步，拦截SQL语句的获取过程，通常是通过AOP或者连接池本身的扩展点（比如HikariCP的ConnectionProxy、Druid的Filter机制）来实现；第二步，对SQL语句进行词法分析和语法解析，识别出SQL的结构，比如SELECT、INSERT、UPDATE、DELETE等关键字，以及表名、字段名、条件表达式等组成部分；第三步，进行安全规则匹配，检测是否存在危险的注入模式，比如单引号未转义、注释符注入、堆叠查询、盲注特征等；第四步，根据校验结果决定放行还是拦截，拦截时可以抛出异常、记录日志、或者替换为安全的参数化查询。
主流连接池的扩展机制对比
目前Java生态中主流的数据库连接池有三个：HikariCP、Druid、C3P0。它们各自提供了不同的扩展点来实现SQL拦截。
HikariCP是目前性能最好的连接池，但它的扩展能力相对有限，主要通过ConnectionProxy接口来包装连接，在getConnection或者创建Statement/PreparedStatement时做拦截。Druid则提供了非常完善的Filter机制，内置了WallFilter（防SQL注入）、StatFilter（统计）等多种过滤器，开箱即用。C3P0支持ConnectionCustomizer和StatementCustomizer，也能实现类似功能，但社区活跃度不如前两者。
从实际开发角度看，如果你用的是Druid，那最简单的方式就是配置WallFilter；如果用HikariCP，就需要自己写一个ConnectionProxy的实现类，在里面做SQL解析和校验。
Druid WallFilter的配置与使用
Druid的WallFilter是阿里巴巴开源的一个SQL防火墙组件，专门用于防止SQL注入攻击。它的配置非常简单，在数据源配置中加入WallFilter即可。
@Bean
public DataSource dataSource() {
DruidDataSource dataSource = new DruidDataSource();
dataSource.setUrl("jdbc:mysql://localhost:3306/mydb");
dataSource.setUsername("root");
dataSource.setPassword("password");
// 配置WallFilter
WallFilter wallFilter = new WallFilter();
wallFilter.setConfig(wallConfig); // 可以自定义策略
wallFilter.setDbType("mysql");
List<Filter> filters = new ArrayList<>();
filters.add(wallFilter);
dataSource.setProxyFilters(filters);
return dataSource;
}
WallFilter默认开启了多种防护规则，包括检测SELECT后面跟注释符、检测UNION注入、检测OR条件绕过、检测堆叠查询等。你还可以通过wallConfig自定义哪些规则开启、哪些关闭，以及针对特定表和字段做白名单配置。
自定义HikariCP连接池SQL拦截器实现
如果你的项目用的是HikariCP，需要自己实现一个SQL校验拦截器。核心思路是创建一个ConnectionProxy，在创建PreparedStatement时对SQL进行校验。
public class SqlValidationConnectionProxy implements ConnectionProxy {
private final Connection target;
private final SqlValidator validator;
public SqlValidationConnectionProxy(Connection target, SqlValidator validator) {
this.target = target;
this.validator = validator;
}
@Override
public PreparedStatement prepareStatement(String sql) throws SQLException {
// 在执行前校验SQL
ValidationResult result = validator.validate(sql);
if (!result.isSafe()) {
throw new SQLException("SQL injection detected: " + result.getReason());
}
return target.prepareStatement(sql);
}
@Override
public PreparedStatement prepareStatement(String sql, int resultSetType, int resultSetConcurrency)
throws SQLException {
ValidationResult result = validator.validate(sql);
if (!result.isSafe()) {
throw new SQLException("SQL injection detected: " + result.getReason());
}
return target.prepareStatement(sql, resultSetType, resultSetConcurrency);
}
// 其他方法直接委托给target
@Override
public Statement createStatement() throws SQLException {
return target.createStatement();
}
@Override
public Connection getTarget() {
return target;
}
}
然后在HikariCP的配置中指定这个代理类：
HikariConfig config = new HikariConfig();
config.setDataSourceClassName("com.mysql.cj.jdbc.MysqlDataSource");
config.addDataSourceProperty("url", "jdbc:mysql://localhost:3306/mydb");
config.addDataSourceProperty("user", "root");
config.addDataSourceProperty("password", "password");
config.setConnectionInitSql("SET NAMES utf8mb4");
// 注册连接代理
config.setDataSourceProperty("connectionInitSql",
"SET NAMES utf8mb4");
HikariDataSource ds = new HikariDataSource(config);
ds.setConnectionProxy(new SqlValidationConnectionProxyFactory(new SqlValidatorImpl()));
SQL校验引擎的核心规则设计
一个好的SQL校验引擎，不能只靠简单的正则匹配，那样误报率太高，会把正常的SQL也拦截掉。需要从以下几个维度来设计规则：
第一，关键词黑名单检测。比如检测SQL中是否包含"DROP TABLE"、"TRUNCATE"、"xp_cmdshell"（SQL Server）、"LOAD_FILE"（MySQL）等高危关键词。但要注意，有些关键词在正常业务中也会出现，比如"DROP"可能出现在注释里，所以需要结合上下文判断。
第二，注释符注入检测。攻击者经常用"--"、"/* */"、"#"等注释符来截断SQL语句，在后面追加恶意代码。校验引擎需要检测注释符后面是否跟着可疑的SQL片段。
第三，堆叠查询检测。用分号";"分隔多条SQL语句执行，这是堆叠注入的典型特征。在大多数业务场景中，一条SQL就是一条语句，不应该出现分号分隔的多条语句。
第四，条件绕过检测。比如"OR 1=1"、"OR 'a'='a'"这类永远为真的条件，以及"UNION SELECT"联合查询注入。需要通过AST（抽象语法树）分析来判断WHERE子句中是否存在恒真条件。
第五，特殊字符检测。单引号、双引号、反引号、转义字符等是否成对出现，是否存在未闭合的情况，这往往是注入的前兆。
基于ANTLR实现SQL语法解析器
如果要做得更专业，建议使用ANTLR4来生成SQL语法解析器。ANTLR是一个强大的语法分析器生成工具，你只需要写一个SQL的语法规则文件，它就能自动生成对应的解析器代码。通过解析器生成AST，然后遍历AST树来做安全校验，比正则匹配准确得多。
// SQL语法片段示例（ANTLR语法文件）
sqlStatement
: selectStatement
| insertStatement
| updateStatement
| deleteStatement
;
selectStatement
: SELECT selectList FROM tableName whereClause?
;
whereClause
: WHERE expression
;
expression
: expression AND expression
| expression OR expression
| columnName comparisonOperator literal
| literal comparisonOperator columnName
;
comparisonOperator
: '=' | '!=' | '>' | '<' | '>=' | '<=' | 'LIKE'
;
有了AST之后，你可以写一个Visitor来遍历树的每个节点，检查是否存在危险模式。比如检测OR节点的两边是否都是恒真表达式，检测是否有UNION节点，检测是否有子查询嵌套等。
拦截器的性能优化策略
SQL校验拦截器会对每一条SQL都做解析和校验，这不可避免地会带来性能开销。如果处理不好，可能会让数据库访问变慢。以下是几个优化方向：
第一，缓存校验结果。对于重复执行的SQL语句，可以用LRU缓存把校验结果存起来，相同的SQL直接返回之前的校验结论，不需要重复解析。但要注意缓存的失效策略，避免表结构变更后缓存还是旧的结果。
第二，分级校验。不是所有SQL都需要做完整的AST解析。可以先用轻量级的规则（比如关键词黑名单、注释符检测）快速过滤掉明显的恶意SQL，只有通过了轻量校验的SQL才进入深度解析阶段。这样大部分正常SQL在第一层就放行了，只有可疑的才进入耗时的深度分析。
第三，异步校验。对于非实时要求高的场景，可以把SQL校验放到异步线程中执行，主线程先拿到连接执行，校验结果通过回调通知。但这种方式有风险，因为如果校验发现问题时SQL已经执行了，所以只适合对延迟敏感但可以接受事后审计的场景。
第四，白名单机制。对于已知安全的SQL模板（比如固定的查询语句），可以提前做好校验并存入白名单，运行时直接跳过校验。这在报表系统、固定接口等场景中非常实用。
拦截器与参数化查询的关系
需要特别强调的是，SQL校验拦截器不能替代参数化查询。参数化查询是从根本上杜绝SQL注入的最佳实践，它通过预编译机制让数据库把SQL结构和数据分开处理，注入代码根本没有执行的机会。而拦截器是一种"兜底"手段，它是在参数化查询被绕过或者开发者偷懒的情况下提供的第二道防线。两者应该配合使用，而不是二选一。
在实际架构中，最理想的方案是：业务代码优先使用参数化查询和ORM框架，连接池层面部署SQL校验拦截器做兜底，同时在数据库层面开启审计日志和权限最小化控制。三层防护叠加，才能把SQL注入的风险降到最低。
实际部署中的注意事项
部署SQL校验拦截器时，有几个坑需要注意。首先是误报问题，如果规则设置太严格，会把正常的复杂SQL也拦截掉，导致业务报错。建议上线初期先设为"告警模式"，只记录不拦截，观察一段时间后再根据日志调整规则。其次是多数据库兼容问题，不同数据库的SQL语法有差异，比如MySQL的反引号、Oracle的双引号、SQL Server的方括号，校验引擎需要针对不同数据库做适配。最后是版本升级问题，当数据库升级或者业务SQL变更时，需要同步更新校验规则，否则会出现新的误报或漏报。
总结与建议
防止SQL注入的数据库连接池SQL校验拦截器，是一种在基础设施层面提供安全防护的有效手段。它的核心价值在于"统一"和"兜底"——统一在连接池这个所有数据库访问的必经之路上做防护，兜住那些因为人为疏忽或者代码规范不到位而产生的注入漏洞。Druid的WallFilter适合快速上手，HikariCP需要自定义代理实现，而基于ANTLR的深度解析方案适合对安全要求极高的场景。不管选择哪种方案，都要记住：拦截器是补充，不是替代，参数化查询才是防SQL注入的根本之道。
