5

我计划使用 Spring MVC 开发一个 Web 应用程序，并试图找出哪个是用于解决 OWASP 前 10 名问题的最佳库。我来看看两个HDIV和ESAPI，谁能帮我理解它们之间的区别。

谢谢您的帮助。

4

2 回答 2

19

首先，我认为这两个 Web 应用程序安全框架的方法和范围是不同的。在某些方面，它们也可以是可以一起使用的补充解决方案。

关于该方法，HDIV 尝试通过与 Web 框架的集成来自动化安全最佳实践。为了实现这种方法，HDIV 已集成到一些最常用的 Java/JVM Web 框架中，例如：Spring MVC、Grails、JSF、Struts 1、Struts 2。请务必注意，如果您的应用程序使用 Web 框架标签要呈现链接和表单，HDIV 不需要在源代码中进行任何更改，只需一个声明性配置（基于 XML 或 Java 配置的配置）。

另一方面，ESAPI 提供了许多开发人员必须在其源代码中使用的实用程序 (API)。换句话说，程序员必须在其源代码中手动包含所有这些实用程序。ESAPI 不依赖于 Web 框架，并且可以在任何 Web 应用程序中使用，因为它没有与 Web 框架集成。

关于范围，HDIV 不涵盖 ESAPI 提供的某些功能，也仅限于支持的 Web 框架。需要注意的是，其中一些特性已经被 Web 框架（Struts、Spring MVC 等）或 Spring Security 等解决方案所覆盖：

  • 身份验证和会话管理：由应用服务器和 Spring Security 覆盖
  • 输出编码：由 Web 框架标签（在这种情况下为 Spring MVC）覆盖，以避免 XSS（转义函数）。未涵盖其他类型的编码，例如避免 SQL 注入的编码。
  • 加密功能：由 Spring Security ( http://docs.spring.io/spring-security/site/docs/3.1.7.RELEASE/reference/crypto.html ) 或 ESAPI 覆盖。我没有比较这两个框架，但看起来它们很相似。
  • 特定于参数的输入验证：被所有 Web 框架（Struts、Spring MVC 等）覆盖

HDIV 被设计为对 Java EE、Spring Security 和 Web 框架提供的安全功能的补充。

为了更深入地了解 HDIV 和 ESAPI 之间的区别，我将尝试比较这两个框架的 OWASP 十大网络风险的功能。我在 github ( https://github.com/ESAPI )中包含了 ESAPI 2.x 和 ESAPI 3.x 中包含的功能。

A1- 注射：

  • HDIV：关于 HTTP 参数的值、url 和 cookie，HDIV 将此漏洞的风险降低到仅来自表单中文本字段的数据，对来自客户端的其余数据应用完整性验证（确保接收到的值是与服务器端生成的相同）。对于表单中包含的文本字段，HDIV 提供通用验证（白名单和黑名单）以避免注入攻击。
  • ESAPI：每个参数的手动输入验证。此功能很有用，但几乎所有 Web 框架都已提供此功能。除此之外，SQL 编码功能可以在查询执行之前以编程方式对 SQL 进行编码。

A2-Broken 身份验证和会话管理：

  • HDIV：不提供针对此网络风险的功能。我们建议使用 Spring Security 进行身份验证，使用应用程序服务器特性（Servlets 规范）进行会话管理。
  • ESAPI：提供程序员必须以编程方式使用的实用程序。

A3-XSS：与 A1 相同，但在这种情况下避免 XSS 风险。

  • HDIV：关于 HTTP 参数的值和 URL，HDIV 将这个漏洞的风险降低到仅来自表单中文本字段的数据，对来自客户端的其余数据应用完整性验证（确保接收到的值相同作为在服务器端生成的）。对于表单中包含的文本字段，HDIV 提供通用验证（白名单和黑名单）以避免注入攻击。HDIV 不包含任何输出编码功能，并将此责任委托给 Web 框架标签，在本例中为 Spring MVC。
  • ESAPI：包括每个参数的手动输入验证。此功能很有用，但几乎所有 Web 框架都已提供此功能。还提供用于输出编码的输出编码功能。程序员必须在源代码中使用此编码器。

A4-不安全的直接对象引用：

  • HDIV：控制在服务器端生成的所有数据（由框架标签处理），确保数据的完整性并消除这种风险。不需要在受支持的 Web 框架内更改任何源代码。需要注意的是，HDIV 支持不同的方法来管理回收的信息：密码（状态在响应中加密发送）、内存（状态存储在 HttpSession 中）、哈希（状态的哈希存储在 HttpSession 和Web 响应中的内容）。
  • ESAPI：有必要创建一个映射以编程方式包含每个参数并将其存储在会话中。
    （http://www.jtmelton.com/2010/05/10/the-owasp-top-ten-and-esapi-part-5-insecure-direct-object-reference/）。此功能包含在 ESAPI 2.x 中，但我没有在 ESAPI 3.x 中找到。

A5-安全配置错误：

  • HDIV：不包括特定的功能，但不允许访问以前不是由服务器发送的资源，避免利用意外行为或访问私有资源。
  • ESAPI：我没有发现任何特性，但我不是 ESAPI 专家。

A6-敏感数据暴露：

A7-缺少功能级别访问控制：

  • HDIV：由于 HDIV 实施的完整性验证，避免了利用此 Web 风险并限制仅使用服务器先前生成的 URL，保持应用程序提供的原始合同。
  • ESAPI：提供一个 API 以编程方式实现它。据我所知，它类似于 Spring Security 提供的功能，程序员必须在源代码中使用这些功能来保护每个 URL。

A8-跨站请求伪造（CSRF）：

  • HDIV：由于 HDIV 与 Web 框架表单标签的集成，为每个表单添加了随机令牌以避免此漏洞。
  • ESAPI：提供生成令牌的 API。此标记必须由程序员手动添加到每个 Web 表单。

A9-使用已知漏洞的组件：

  • HDIV：不包括特定功能，但由于 HDIV 对用户施加的交互限制，在许多情况下无法利用已知漏洞。
  • ESAPI：我在文档中看不到任何功能，但我不是 ESAPI 专家。

A10-Unvalidated redirects and forwards：该漏洞主要与服务器端不可编辑数据或先前生成的数据的操作有关，与A4非常相似。

  • HDIV：控制服务器发送的所有数据，不允许重定向到恶意网站。
  • ESAPI：ESAPI 提供的解决方案将与 A4 (AccessReferenceMap) 提供的解决方案相同，必须在源代码中使用。

罗伯托·贝拉斯科·萨拉索拉（HDIV 团队）

于 2015-01-20T20:44:41.280 回答
5

首先，OWASP 的 ESAPI 不再是 OWASP 的旗舰产品：该库的主要开发工作停滞不前，而 2.1 版本只是为了修复一个主要的 CVE。看起来定期的贡献会进入 HDIV 库。HDIV 也有丰富的资源演示如何将其集成到常见的 Web 框架中——他们的文档涵盖 Spring、Grails，当然它从 Struts1 和 Struts2 开始。

HDIV 提供了一个关于其架构的简报。虽然我真的不喜欢它说它消除了XSS（它没有，也不能），但基本架构看起来相当不错。

恕我直言，在搜索文档时 HDIV 似乎唯一缺少的是一种规范化作为入侵检测的方法。从理论上讲，由于它依赖于对不可编辑数据采取的散列，因此您会收到有人试图篡改您的参数的警告。但是，使用 esapi，它会检测多重编码攻击并相应地通知您——它会为您提供更好的信息。（参数名称、用户 ID 和尝试的输入。）

此外，HDIV 似乎没有 ESAPI 提供的几个功能：

  • 防止日志注入
  • 身份验证机制 --> 虽然很少使用，但它对 Java 安全性的实现确实比开箱即用的更好。它还有一个直观的用户模型。
  • 经过良好测试的加密实现 --> 如果您想要安全使用 Java 加密，已经针对 ESAPI 运行了安全评估。
  • SQL 注入防御可用于（由于某种原因）您不能使用参数化查询或存储过程的情况。
  • 特定于上下文的输出编码。虽然由于 ESAPI 目前的灰尘收集状态，如果您需要编码，我会使用它来代替。. 重要的是要注意正确的输出转义比任何输入过滤/验证要好 10M 倍。您可以跳过 WAF，但仍然具有出色的安全性。相反的说法是错误的。
  • 参数特定输入验证的细粒度控制。WAF 方法只是标记通用字段类型，并对规则类型应用一刀切的方法。ESAPI 让您可以使用validation.properties.
于 2015-01-08T17:05:08.713 回答