spring-mvc - 使用 Hibernate Validator(JSR 303) 与其他框架(ESAPI、Apache Commons 等)进行输入验证

Question

我查看了用于输入验证的各种框架，包括 Hibernate Validator impl 用于 JSR 303 bean 验证，以及 ESAPI 验证器接口(interface)及其DefaultValidator执行。

ESAPI 输入验证通过 ESAPI.properties 文件围绕正则表达式模式匹配展开。

ESAPI 路线 :

ESAPI.properties:

Validator.SafeString=[A-Za-z0-9]{0,1024}$

Java类:

ESAPI.validator().isValidInput("Name","darthvader", "SafeString", 255, false)

Hibernate 验证器/Spring MVC 路由

Hibernate 涉及使用各种约束注释(@NotNull、@Size、@Min、@Pattern、@Valid 等)来注释您的 bean。并为验证规则集成 Spring MVC。

@RequestMapping(value = "/appointments", method = RequestMethod.POST)
public String add(@Valid User user, BindingResult result) {
    ....
}

似乎使用 Hibernate Validator/Spring MVC 提供了与正则表达式匹配等类似的功能。有没有 优势 在 Hibernate 验证器 api 上使用 ESAPI 库？也许用于 SQL 注入(inject)/XSS 或任何类似性质的东西？为 ESAPI 输入验证框架提供开箱即用的 XSS/SQL 注入(inject)安全性？与使用其中一个或另一个相比的任何真正优势。提前致谢。

回答我自己的问题:
我想我为这篇文章找到了自己的解决方案。使用 Hibernate/Spring MVC 可以实现非常强大的 bean 验证功能。而Hibernate提供了@SafeHtml、@Pattern等安全注解。基本上我们可以设置一组提供bean验证的组合注解。 http://docs.jboss.org/hibernate/validator/5.0/reference/en-US/html_single/

Answer 1

Are there any advantages of using ESAPI library over Hibernatevalidator api?

我是一名安全人员，所以我要说的第一件事是，在您担心输入验证之前，请确保在您担心安全级别之前，您已经将上下文转义到后端的科学输入验证。如果数据要进入数据库，请确保您将其转义以进行查询(或准备好的语句或存储的过程)，并且在处理该数据时，将其正确转义以发送到下游 Web 服务/命令行/等或当向用户重新呈现该数据时(html/javascript/actionscript/etc)
既然我已经排除了强制性部分，两个库都用于非常不同的事情。 ESAPI 的一个主要设计目标是，它旨在帮助保护那些不幸从一开始就没有安全机制设计的应用程序。例如，它为 SQL 注入(inject)预先打包了编码数据的技术，由于复杂性/时间限制等，可能无法立即将其重写为参数化查询或存储过程。然而，Hibernate 被设计为 JPA 实现(如您所指出的)，并引用 JSR specification将对 Hibernate 的实现有所启发:

Validating data is a common task that occurs throughout anapplication, from the presentation layer to the persistence layer.Often the same validation logic is implemented in each layer, provingto be time consuming and error-prone. To avoid duplication of thesevalidations in each layer, developers often bundle validation logicdirectly into the domain model, cluttering domain classes withvalidation code that is, in fact, metadata about the class itself.

这显然是为了处理域层验证，我偷偷怀疑 Hibernate 确实在应用程序的错误层提供了一些便利方法——可能是糟糕的应用程序设计从 Dao 层一直传递域对象到表示层。您不应该在域模型中清理或删除可能的 HTML。您应该将它放在最初从 HttpRequest 对象中提取数据的 Controller /服务层。验证数据后，将数据转换为域对象，然后将其传递到后端。此外，即使使用 Hibernate @SafeHtml如果/当该数据是合法的 javascript 但不是合法的 HTML，则不能保护您免受 javascript 攻击。 This这就是为什么输出转义比输入过滤重要 100 倍的原因。
回答你的第一个问题:

Are there any advantages of using ESAPI library over Hibernate validator api?

首先，Hibernate 中的“@SafeHtml”不是 JSR 的一部分
303 规范，因此通过使用它，您将绑定(bind)您的 JPA
直接实现Hibernate。这会损害维护。

ESAPI 的验证器为您提供更改验证的能力
通过 validator.properties这意味着你可以处理
生产中的业务问题，无需进行开发
创建一个全新的构建，就像目前发生在
注释驱动模型。

ESAPI 的验证器由 security 设计、编写和测试
专家。

这是最重要的:ESAPI 为您提供ESAPI.encoder().canonicalize()隐式使用的方法
任何 ESAPI 的 Validator.getValidHtml(args...)来电。这种方法
它本身可以让您确定是否有人正在尝试
针对您的应用程序的多重编码攻击。类似的调用
在我知道的任何其他 Java 安全库中都不存在，
绝对不在 Hibernate 的验证器实现中——我会
永远不要期望 Hibernate 有这个调用，因为它是一个域库。

4 的重要性怎么强调都不为过，因为多重编码攻击是大多数 XSS 被注入(inject)野外应用程序的方式。这会强制所有输入最多为单个 URL 编码，并允许您立即识别尝试将此类输入输入应用程序的用户。
ESAPI 确实有一个主要缺点。截至 2014 年秋季，由于社区发展停滞不前，它失去了 OWASP 的旗舰地位。时间会证明球是否开始使用 ESAPI 3.0。