使用Hibernate的Restrictions.eq()等方法能否防范SQL注入？是否需输入验证？

核心结论：Restrictions系列方法可抵御SQL注入 #

• Restrictions.eq()、Restrictions.in()、Restrictions.ge()这类Criteria API方法完全可以抵御SQL注入。原因很简单：Hibernate的Criteria API会自动将用户输入转换为参数化查询的参数，不会把输入内容直接拼接进SQL语句中。

比如你提供的示例代码：

String vulnerable = // 来自用户界面的参数
Criteria ct = this.getCriteria();
ct.add(Restrictions.eq("propertyName", vulnerable));

Hibernate最终生成的SQL是参数化形式（类似SELECT ... WHERE propertyName = ?），用户输入的内容只会作为?对应的参数值被数据库安全处理，根本不会被解析为SQL语句的一部分，所以不存在SQL注入风险。

为什么OWASP说“还应该做验证”？ #

OWASP示例里的注释// This should REALLY be validated too，和SQL注入防护无关，它指的是业务逻辑层面的输入验证：

• 比如用户输入的商品描述长度超过数据库字段的限制，或者包含业务上不允许的违禁内容，或者格式不符合要求（比如要求纯文本却输入了HTML代码）
• 这类验证是为了保证数据符合业务规则、避免脏数据进入系统，属于业务安全和数据质量的范畴，和SQL注入防护是两个独立的需求。

要不要做输入验证？ #

• 如果只关注SQL注入防护：直接使用Restrictions系列方法就足够安全，不需要额外做注入相关的过滤或转义。
• 如果考虑系统整体的健壮性和业务合规：必须做输入验证，比如校验输入的长度、格式、合法取值范围等，这是保障系统稳定和数据质量的必要步骤，和注入防护并不冲突。

内容的提问来源于stack exchange，提问作者Julian Vicente