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

Question

我查看了各种输入验证框架,包括用于JSR 303 bean验证的Hibernate Validator impl,以及ESAPI验证器接口及其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 Validator/Spring MVC路由

Hibernate涉及使用各种约束注释来注释bean(@NotNull,@ Size,@ Min,@ Pattern,@ Valid等).并将Spring MVC与验证规则集成在一起.

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

看起来像使用Hibernate Validator/Spring MVC提供与正则表达式匹配等相似的功能.使用ESAPI库比Hibernate验证器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

使用ESAPI库比Hibernate验证器api有什么优势吗？

我是一个安全人员,所以我要说的第一件事就是在你担心输入验证之前,确保在你担心安全级别之前,你已经将背景转移到了后端的科学输入验证.如果数据要进入数据库,请确保您为查询(或准备好的语句或存储过程)转义它,并在处理该数据时,正确地将其转义以发送到下游Web服务/命令行/ etc或何时向用户重新呈现该数据(html/javascript/actionscript/etc)

现在我已经完成了必须的工作,两个库都用于非常不同的事情.ESAPI的一个主要设计目标是,它旨在帮助保护那些不幸的应用程序,从一开始就没有安全机制.例如,它预先打包编码SQL注入数据的技术,由于复杂性/时间限制等原因,这些技术可能无法立即重写为参数化查询或存储过程.然而,Hibernate被设计为JPA实现(正如您所指出的),并且对JSR规范的引用将对Hibernate的实现有所启发:

验证数据是在整个应用程序中从表示层到持久层发生的常见任务.通常在每一层中实现相同的验证逻辑,证明是耗时且容易出错的.为了避免在每个层中重复这些验证,开发人员通常将验证逻辑直接捆绑到域模型中,使用验证代码来混淆域类,实际上,验证代码是关于类本身的元数据.

这显然是用于处理域层验证,我怀疑Hibernate确实在应用程序的错误层提供了一些便利方法 - 可能是糟糕的应用程序设计从Dao层一直传递域对象到表示层.您不应该在域模型中清理或发布可能的HTML.您应该在最初从HttpRequest对象中提取数据的Controller/Service层进行调整.验证数据后,将数据转换为Domain对象,然后将其传递给后端.此外,即使Hibernate @SafeHtml不能保护您免受javascript攻击,如果/当这些数据是合法的javascript而不是合法的HTML. 这个 这就是为什么输出转义比输入过滤重要100倍的原因.

回答你的第一个问题:

使用ESAPI库比Hibernate验证器api有什么优势吗？

1. 首先,Hibernate中的"@SafeHtml"不是JSR 303规范的一部分,因此通过使用它,您可以将JPA实现直接绑定到Hibernate.这会损害维护.
2. ESAPI的验证器为您提供了更改验证的功能,通过validator.properties这种验证,您可以处理生产中的业务问题,而无需进行开发以创建当前在注释驱动模型中发生的全新构建.
3. ESAPI的验证器由安全专家设计,编写和测试.
4. 这是最重要的事情:ESAPI为您提供了ESAPI.encoder().canonicalize()在任何ESAPI Validator.getValidHtml(args...)调用中隐式使用的 方法.此方法本身允许您确定某人是否正在尝试针对您的应用程序进行多重编码攻击.在我所知道的任何其他Java安全库中都不存在类似的调用,绝对不是在Hibernate的验证器实现中 - 并且我永远不会期望Hibernate从它的域库中获得该调用.

由于多次编码攻击是大多数XSS被注入野外应用程序的方式,因此不能过分夸大其重要性.这会强制所有输入最多为单URL编码,并允许您立即识别尝试将此类输入输入应用程序的用户.

ESAPI 确实有一个主要缺点.截至2014年秋季,由于社区发展停滞,它在OWASP失去了旗舰地位.时间将告诉球是否开始用ESAPI 3.0滚动.

Answer 2

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

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

希望这能有所帮助:)