使用Hibernate Validator(JSR303)对其他框架(ESAPI、Apache Commons等）进行输入验证

Question

我研究了各种输入验证框架，包括用于JSR303 bean验证的Hibernate Validator impl，以及ESAPI Validator接口及其DefaultValidator实现。

ESAPI输入验证围绕通过ESAPI.properties文件进行的regex模式匹配。

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提供了类似的功能和regex匹配等，使用ESAPI库比使用Hibernate validator API有什么优势吗？可能是SQL注入/XSS或任何类似性质的东西？针对ESAPI输入验证框架的XSS/SQL注入的安全性？任何真正的优势比使用一个或另一个。提前道谢。

回答我自己的问题：我想我为这个职位找到了自己的解决方案。使用Hibernate/spring MVC允许非常健壮的bean验证功能。并且Hibernate提供了诸如@safeHTML、@pattern等安全注释。基本上，我们可以设置一组复合注释来提供bean验证。http://docs.jboss.org/hibernate/validator/5.0/reference/en-us/html_single/

Answer 1

仅供参考，我基于Hibernate Validator创建了一组专用于输入验证的注释：

https://github.com/righttod/hibernate-validator-security-contribs

希望这能有所帮助：）

Answer 2

与Hibernate验证器API相比，使用ESAPI库有什么优势吗？

我是一个安全专家，所以我要说的第一件事是，在担心输入验证之前，确保在担心安全级别的输入验证之前，在后端有上下文转义到一个科学。如果数据要进入数据库，请确保您为查询（或准备好的语句或存储的过程）转义它，并且在处理该数据时，正确地转义它，以便将其发送到下游web服务/命令行/etc或将该数据重新呈现给用户（HTML/JavaScript/ActionScript/etc）

现在，我已经排除了必须的部分，这两个库用于非常不同的事情。ESAPI的一个主要设计目标是，它的设计目的是帮助保护那些从一开始就被设计成没有安全机制的应用程序的安全。例如，它预先打包了用于SQL注入的数据编码技术，由于复杂性/时间限制/等原因，这些技术可能不能立即重写为参数化查询或存储过程。但是，Hibernate是作为一个JPA实现设计的（如您所指出的），对JSR规范的引用将对Hibernate的实现产生一些启示：

验证数据是一项常见的任务，在整个应用程序中，从表示层到持久层都有。通常在每一层中实现相同的验证逻辑，这证明是耗时和容易出错的。为了避免在每一层中重复这些验证，开发人员经常将验证逻辑直接捆绑到域模型中，用验证代码（实际上是关于类本身的元数据）来杂乱地处理域类。

这显然是为了处理域层验证，我偷偷地怀疑Hibernate确实在应用程序的错误层提供了一些方便的方法--可能是一个糟糕的应用程序设计将域对象从Dao层一直传递到表示层。您不应该在您的域模型中清理或打赌可能的HTML。您应该在最初从HttpRequest对象中提取数据的控制器/服务层进行pung操作。一旦数据被验证，将数据转换为一个域对象，然后将其传递到后端。此外，即使使用Hibernate@safeHTML也不能保护您免受javascript攻击，如果数据是合法的javascript而不是合法的HTML。这就是为什么输出转义比输入过滤重要100倍的原因。

回答你的第一个问题：

与Hibernate验证器API相比，使用ESAPI库有什么优势吗？

1. 首先，Hibernate中的“@SafeHTML”不是JSR303规范的一部分，因此通过使用它，您可以将JPA实现直接绑定到Hibernate。这会损害维护。
2. ESAPI的验证器为您提供了通过validator.properties更改验证的能力，这意味着您可以在生产中处理业务问题，而不必像当前在批注驱动模型中所发生的那样进入开发阶段来创建一个全新的构建。
3. ESAPI的验证器是由安全专家设计、编写和测试的。
4. 这是最重要的一点：ESAPI为您提供了ESAPI.encoder().canonicalize()方法，该方法在ESAPI的任何validator.getValidHTML（args...）调用中隐式使用。此方法本身允许您确定是否有人正在尝试对您的应用程序进行多重编码攻击。类似的调用在我所知道的任何其他Java安全库中都不存在，在Hibernate的验证器实现中肯定不存在--而且我绝不会期望Hibernate会有这个调用，因为它是一个域库。

ESAPI确实有一个主要缺点。2014年秋季，由于社区发展停滞不前，它失去了OWASP的旗舰地位。用ESAPI3.0是否开始了，时间会告诉我们。