防止SQL注入的ORM配置项检查

ORM框架并不能完全杜绝SQL注入，尤其是当开发者使用原生SQL或动态拼接查询片段时。很多团队以为用了Hibernate、MyBatis、Entity Framework就高枕无忧了，实际上大量注入漏洞恰恰发生在ORM的误用场景中。问题不在于ORM本身是否安全，而在于配置项是否开启了应有的防护、参数绑定是否严格执行、以及那些看似无害的灵活功能是否被错误地交给了用户输入。

几乎所有主流ORM都支持参数化查询，但关键在于是否强制启用。以MyBatis为例，Mapper XML中的${}和#{}有着本质区别。#{}会通过PreparedStatement进行参数绑定，而${}则是直接字符串替换。检查点非常明确：全局搜索Mapper文件中是否存在${}符号，如果存在，逐一确认其变量是否来自用户输入。更严格的做法是在框架配置层面直接禁用${}，比如在MyBatis的SQL注入检查插件中设置黑名单规则。对于JPA/Hibernate，需要检查是否误用了JPQL拼接，比如通过criteriaBuilder.literal()或直接字符串拼接构造查询条件。正确的做法是始终使用setParameter()方法，并且开启Hibernate的hibernate.query.fail_on_pagination_over_collection_fetch和hibernate.query.jpaql.strict_compliance这类严格模式配置，它们会在语法层面拒绝可能危险的查询结构。

这是ORM使用中最容易被忽视的高危点。业务上经常需要前端传入排序字段名和排序方向，很多开发者图省事，直接将接收到的字段名拼接到ORDER BY后面。ORM的动态查询功能如JPA的Sort、MyBatis的动态SQL标签，如果参数没有经过白名单过滤，注入就发生了。检查方法是：找到所有接收排序参数的Controller或Service方法，确认是否存在一个显式的白名单集合，例如定义一个包含允许排序字段的Set或Enum，任何传入的字段名必须在该集合中才能继续执行。代码层面可以这样实现：

private static final Set<String> ALLOWED_SORT_FIELDS = Set.of("id", "username", "email", "createTime");

public List<User> getUsersByOrder(String orderBy, String direction) {
    if (orderBy == null || !ALLOWED_SORT_FIELDS.contains(orderBy)) {
        throw new IllegalArgumentException("Invalid sort field");
    }
    Sort.Direction dir = "desc".equalsIgnoreCase(direction) ? Sort.Direction.DESC : Sort.Direction.ASC;
    return repository.findAll(Sort.by(dir, orderBy));
}

如果使用的是JPA Criteria API，同样需要确保orderBy方法中的Path对象来自元模型而非字符串输入。无论哪种ORM，排序字段的白名单校验必须存在，这是硬性指标。

ORM负责将实体属性映射到数据库列，正常情况下列名和表名由框架自动处理，不会产生注入。但有些场景需要手动指定列名或表名，比如使用@Column注解的name属性、@Table注解、或者动态表名功能。检查项包括：是否在注解中使用了外部可控的变量？是否通过配置文件动态生成表名且该配置可被用户影响？对于需要动态表名的场景，比如SaaS系统的租户隔离，表名必须来自服务端受信源而非前端参数。Hibernate的拦截器或物理命名策略中如果涉及动态拼接，同样需要审查。更底层的配置项是连接字符串中的characterEncoding和useServerPrepStmts参数，例如MySQL连接URL应包含useServerPrepStmts=true&cachePrepStmts=true，这能确保服务端预处理语句被真正启用，从协议层面减少SQL注入的传输路径。

ORM的批量更新或删除操作如果使用原生SQL，风险极高。检查所有标注了@Query并设置nativeQuery=true的JPA Repository方法，以及MyBatis中select、update、delete标签内直接书写的SQL语句。这些地方必须保证所有变量都通过参数绑定传入，而不是字符串拼接。特别要注意IN子句的处理，很多开发者因为参数数量不固定而选择拼接，这是典型的错误做法。正确方式是利用ORM提供的动态IN参数绑定能力，例如JPA的(:ids)配合集合参数，MyBatis的foreach标签。如果ORM版本较老不支持，应当升级框架版本而非妥协使用拼接。另外，检查是否配置了SQL执行日志的输出级别，生产环境中应避免打印完整的SQL语句和参数，防止注入攻击的载荷通过日志泄露后再被二次利用。

调用存储过程时，ORM通常提供两种方式：通过命名查询或直接执行CALL语句。如果使用原生CALL语句拼接参数，同样存在注入风险。检查所有StoredProcedureQuery或@Procedure注解的使用，确认入参是否通过registerStoredProcedureParameter注册了正确的JDBC类型，并且传值过程中没有经过字符串拼接。输出参数的类型定义也必须严格，防止存储过程内部返回恶意构造的游标或动态SQL结果。在数据库端，存储过程本身也应遵循参数化原则，避免在过程体内使用EXEC或sp_executesql拼接字符串，但这是DBA层面的检查，从应用层ORM配置角度，我们至少能确保调用方式的安全。

虽然这看起来不属于传统SQL注入，但级联操作配置不当会导致数据泄露或意外修改，其危害等级不亚于注入。检查所有实体关联的cascade属性，是否设置了过宽的级联类型，比如对无需持久化传播的关联也配置了CascadeType.ALL。FetchType的配置同样关键，懒加载异常处理不当可能导致开发者写出一次性加载全部关联的查询，进而为绕过权限检查提供条件。更隐蔽的是，Hibernate的@Filter和@Where注解如果包含动态条件且拼接了用户输入，同样构成注入。检查这些注解中的SQL片段是否硬编码，任何动态部分都必须走参数绑定或白名单。

当应用连接多个数据库或配置了读写分离时，容易出现部分数据源的ORM配置遗漏安全检查的情况。检查项包括：所有数据源的配置文件是否都启用了相同的安全参数？读写分离的路由规则中，是否根据SQL类型正确路由，并且只读数据源的连接是否也开启了预编译和转义设置？有时开发者会在只读库上放松警惕，使用更宽松的查询方式，这恰好可能成为注入点。配置管理上，建议将ORM安全相关的基础设置抽取为公共模板，通过配置中心统一下发，避免各数据源各自为战。

很多SQL注入并非来自代码编写，而是ORM框架本身的漏洞。检查当前使用的ORM版本号，对照官方发布的安全公告，确认是否存在已公开的CVE漏洞。例如某些旧版本的Hibernate在处理某些特殊字符或JPQL函数时存在绕过参数绑定的缺陷，MyBatis的某些插件接口也可能被恶意利用。版本检查应纳入CI/CD流水线，定期自动执行。如果无法立即升级，需要确认官方是否提供了配置层面的缓解措施，比如禁用某个危险函数、开启严格解析模式等，并确保这些配置项已实际生效。

许多项目使用代码生成器自动创建CRUD接口，这些生成器默认生成的代码往往包含模糊查询或动态条件构造。检查生成模板中是否使用了安全的参数绑定方式，特别是LIKE查询的拼接，必须使用CONCAT函数或参数占位符，而非在代码层面用百分号包裹后直接拼入SQL。同时，生成的分页查询、导出功能的SQL片段也需要逐项审查。如果使用的是第三方低代码平台集成的ORM能力，需要向厂商确认其SQL构造机制，并要求提供安全配置文档。

最后一道防线是ORM的运行时行为监控。配置项包括：是否开启了SQL异常时的详细错误信息返回？生产环境中必须将hibernate.show_sql和mybatis.configuration.log-impl这类详细日志输出关闭，或者至少将日志级别控制在DEBUG以下且不对外暴露。数据库错误信息不应直接返回给前端，ORM抛出的PersistenceException或DataAccessException应当被全局异常处理器捕获，转换为通用的错误响应。同时，建议配置SQL执行时长的慢查询阈值，以及单次查询返回行数的上限，这些参数能有效缓解注入成功后的数据拖取行为。在应用层还可以集成RASP或WAF类工具，对ORM发出的SQL进行二次语法分析，识别异常的模式注入特征。

ORM的安全配置检查不是一次性工作，而是需要嵌入到代码评审清单、自动化测试用例和部署验收标准中的持续过程。每一个配置项的背后，都对应着一类可能被绕过防护的场景。真正有效的防护，来自于对每一条SQL生成路径的严格约束，以及对框架底层行为的清晰掌控。