5

我查看了用于输入验证的各种框架，包括用于 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 涉及使用各种约束注释（@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 注入/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/

4

2 回答 2

6

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

我是一名安全人员，所以我要说的第一件事是，在您担心输入验证之前，请确保在您担心安全级别之前，您已经将上下文转义到后端的科学输入验证。如果数据要进入数据库，请确保您将其转义以进行查询（或准备好的语句或存储的过程），并且在处理该数据时，将其正确转义以发送到下游 Web 服务/命令行/等或当向用户重新呈现该数据时（html/javascript/actionscript/etc）

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

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

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

回答你的第一个问题：

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

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

4 的重要性怎么强调都不为过，因为多重编码攻击是大多数 XSS 被注入野外应用程序的方式。这会强制所有输入最多为单个 URL 编码，并允许您立即识别尝试将此类输入输入应用程序的用户。

ESAPI确实有一个主要缺点。截至 2014 年秋季，由于社区发展停滞不前，它失去了 OWASP 的旗舰地位。时间会证明球是否开始使用 ESAPI 3.0。

于 2015-01-22T14:30:10.067 回答
0

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

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

希望这可以帮助:)

于 2014-02-23T10:09:29.810 回答