HDIV 和 ESAPI 之间的区别
Difference between HDIV and ESAPI
我计划使用 Spring MVC 开发一个 Web 应用程序，并试图找出哪个库是解决 OWASP 前 10 大问题的最佳库。我来看看HDIV和ESAPI这两个，谁能帮我理解一下它们之间的区别。
感谢您的帮助。
首先，OWASP 的 ESAPI 不再是 OWASP 的旗舰产品：库的主要开发工作停滞不前，2.1 版本只是为了修复一个主要的 CVE。看起来像定期贡献进入 HDIV 库。 HDIV 也有丰富的资源演示如何将其集成到常见的 Web 框架中——他们的文档涵盖 Spring、Grails，当然它以 Struts1 和 Struts2 开头。
HDIV provides a powerpoint 谈论它的体系结构。虽然我真的不喜欢它说它 eliminates XSS（它没有，也不能）基本架构看起来很不错。
恕我直言，HDIV 在搜索文档时似乎唯一缺少的是一种规范化入侵检测方法。从理论上讲，因为它依赖于对不可编辑的数据进行哈希处理，所以您会收到警告，有人试图篡改您的参数。然而，使用 esapi，它会检测多重编码攻击并相应地通知您——它为您提供了更好的信息。 （参数名称、用户 ID 和尝试的输入。）
此外，HDIV 似乎没有 ESAPI 提供的几个功能：
- 防止日志注入
- 身份验证机制 --> 虽然很少使用，但它在 Java 安全性方面确实比开箱即用的更好。它还具有用户的直观模型。
- 经过良好测试的加密实现 --> 如果您想要安全使用 Java 加密，安全评估已针对 ESAPI 运行。
- SQL 可以在（出于某种原因）不能使用参数化查询或存储过程的情况下使用注入防御。
- 上下文特定的输出编码。虽然由于 ESAPI 目前的积尘状态，如果您需要编码，我会使用 this instead.。重要的是要注意，正确的输出转义比任何输入都要好 10M 倍 filtering/validation。您可以跳过 WAF，仍然拥有出色的安全性。反过来说是假的。
- 对特定于参数的输入验证进行细粒度控制。 WAF 方法只是标记通用字段类型，并对规则类型应用一种一刀切的方法。 ESAPI 让您可以通过使用
validation.properties 获得您想要的细粒度。
首先，我认为这两个 Web 应用程序安全框架的方法和范围是不同的。在某些方面，它们也可以是互补的解决方案，可以一起使用。
关于该方法，HDIV 尝试通过
与网络框架的集成。为了实施这种方法，HDIV 已集成到一些最常用的 Java/JVM Web 框架中，例如：Spring MVC、Grails、JSF、Struts 1、Struts 2. 重要的是要注意，如果您的应用程序使用 web 框架标签来呈现链接和表单，HDIV 不需要在源代码中进行任何更改，只需一个声明性配置（XML 或 Java 基于配置的配置).
另一方面，ESAPI 提供了开发人员必须在其源代码中使用的许多实用程序 (APIs)。换句话说，程序员必须在他们的源代码中手动包含所有这些实用程序。 ESAPI 不依赖于 Web 框架，可以在任何 Web 应用程序中使用，因为它没有与 Web 框架集成。
关于范围，HDIV 不涵盖 ESAPI 提供的一些功能，也仅限于支持的 Web 框架。重要的是要注意，其中一些功能已经包含在 Web 框架（Struts、Spring MVC 等）或 Spring 安全性：
等解决方案中
- 身份验证和会话管理：由应用程序服务器涵盖
和 Spring 安全性
- 输出编码：由网络框架标签覆盖（在这种情况下Spring
MVC）来避免 XSS（转义函数）。不包括其他类型的编码，例如避免 SQL 注入的编码。
- 加密函数：Spring 安全性涵盖
(http://docs.spring.io/spring-security/site/docs/3.1.7.RELEASE/reference/crypto.html)
或 ESAPI。我没有比较这两个框架，但看起来它们
相似。
- 特定于参数的输入验证：涵盖所有 Web 框架
（Struts、Spring MVC 等）
HDIV 旨在补充 Java EE、Spring 安全和 Web 框架提供的安全功能。
为了更深入地了解 HDIV 和 ES 之间的区别API 我将尝试比较这两个框架的功能以涵盖 OWASP 十大网络风险。我已经将 ESAPI 2.x 和 ESAPI 3.x 中包含的功能包含在 github (https://github.com/ESAPI).
A1- 注入：
- HDIV：关于 HTTP 参数值、url 和 cookies HDIV 减少
此漏洞的风险仅来自文本的数据
表单中的字段，对其余部分应用完整性验证
来自客户端的数据（确保接收到的值是
与服务器端生成的相同）。对于包含的文本字段
在表单中，HDIV 提供通用验证（白名单和
黑名单）以避免注入攻击。
- ESAPI：每个参数的手动输入验证。这个功能很有用
但几乎所有的网络框架都已经提供了。除此之外，SQL 编码功能可在之前以编程方式对 SQL 进行编码
查询执行。
A2-损坏的身份验证和会话管理：
- HDIV：不提供针对此 Web 风险的功能。我们推荐
使用 Spring 安全性进行身份验证和应用程序服务器
用于会话管理的功能（Servlets 规范）。
- ESAPI：提供必须以编程方式使用的实用程序
程序员。
A3-XSS：与A1相同，但在这种情况下可以避免XSS风险。
- HDIV：关于 HTTP 参数值和 URL HDIV 降低风险
此漏洞仅适用于来自文本字段的数据
在表单中，对其余数据应用完整性验证
来自客户端（确保接收到的值与
在服务器端生成）。对于表单中包含的文本字段，
HDIV 提供通用验证（白名单和黑名单）以便
避免注入攻击注入攻击。 HDIV 不包括任何
输出编码功能并将此责任委托给网络
框架标签，在本例中为 Spring MVC。
- ESAPI：包括每个参数的手动输入验证。这个功能是
很有用，但几乎所有 Web 框架都已经提供了。还提供输出
输出编码的编码特征。程序员必须在源代码中使用此编码器。
A4-不安全的直接对象引用：
- HDIV：控制服务器端生成的所有数据（由
框架标签）确保数据的完整性并消除
这种风险。不需要在支持的范围内更改任何源代码
网络框架。重要的是要注意 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-敏感数据暴露：
- HDIV：提供保密功能以隐藏 HTTP 的值
参数。 HDIV 不提供任何加密 API.
- ESAPI: 提供加密 API 来加密、解密等。 更多
详细信息：https://github.com/ESAPI/esapi-java-legacy/blob/master/documentation/esapi4java-core-2.0-crypto-design-goals.doc。
此功能包含在 ESAPI 2.x 中，但我没有在其中找到
ESAPI 3.x.
A7-缺少功能级别访问控制：
- HDIV：感谢 HDIV 实施的完整性验证，
避免利用此 Web 风险并限制使用仅 URLs
先前由服务器生成，保持原始合约
由应用程序提供。
- ESAPI：提供了一个 API 以编程方式实现它。据我所知
知道它类似于 Spring Security 提供的功能
程序员必须在源代码中使用它来保护每个 URL.
A8-跨站请求伪造 (CSRF)：
- HDIV：为每个表单添加随机标记以避免此漏洞
感谢 HDIV 与 Web 框架表单标签的集成。
- ESAPI：提供一个API来生成令牌。此令牌必须由
程序员手动处理每个 Web 表单。
A9-使用具有已知漏洞的组件：
- HDIV：不包括特定功能，但谢谢
HDIV 在许多方面对用户施加的交互限制
cases 无法利用已知漏洞。
- ESAPI：我没有在文档中看到任何功能，但我不是
ES专家API.
A10-Unvalidated redirects and forwards：该漏洞主要与不可编辑数据或之前在服务器端生成的数据的操作有关，与A4非常相似。
- HDIV：控制服务器发送的所有数据，不允许
重定向到恶意网站。
- ESAPI: ESAPI提供的解决方案将与提供的相同
对于必须在源中使用的 A4 (AccessReferenceMap)
代码。
Roberto Velasco Sarasola（HDIV 队）
我计划使用 Spring MVC 开发一个 Web 应用程序，并试图找出哪个库是解决 OWASP 前 10 大问题的最佳库。我来看看HDIV和ESAPI这两个，谁能帮我理解一下它们之间的区别。
感谢您的帮助。
首先，OWASP 的 ESAPI 不再是 OWASP 的旗舰产品：库的主要开发工作停滞不前，2.1 版本只是为了修复一个主要的 CVE。看起来像定期贡献进入 HDIV 库。 HDIV 也有丰富的资源演示如何将其集成到常见的 Web 框架中——他们的文档涵盖 Spring、Grails，当然它以 Struts1 和 Struts2 开头。
HDIV provides a powerpoint 谈论它的体系结构。虽然我真的不喜欢它说它 eliminates XSS（它没有，也不能）基本架构看起来很不错。
恕我直言，HDIV 在搜索文档时似乎唯一缺少的是一种规范化入侵检测方法。从理论上讲，因为它依赖于对不可编辑的数据进行哈希处理，所以您会收到警告，有人试图篡改您的参数。然而，使用 esapi，它会检测多重编码攻击并相应地通知您——它为您提供了更好的信息。 （参数名称、用户 ID 和尝试的输入。）
此外，HDIV 似乎没有 ESAPI 提供的几个功能：
- 防止日志注入
- 身份验证机制 --> 虽然很少使用，但它在 Java 安全性方面确实比开箱即用的更好。它还具有用户的直观模型。
- 经过良好测试的加密实现 --> 如果您想要安全使用 Java 加密，安全评估已针对 ESAPI 运行。
- SQL 可以在（出于某种原因）不能使用参数化查询或存储过程的情况下使用注入防御。
- 上下文特定的输出编码。虽然由于 ESAPI 目前的积尘状态，如果您需要编码，我会使用 this instead.。重要的是要注意，正确的输出转义比任何输入都要好 10M 倍 filtering/validation。您可以跳过 WAF，仍然拥有出色的安全性。反过来说是假的。
- 对特定于参数的输入验证进行细粒度控制。 WAF 方法只是标记通用字段类型，并对规则类型应用一种一刀切的方法。 ESAPI 让您可以通过使用
validation.properties获得您想要的细粒度。
首先，我认为这两个 Web 应用程序安全框架的方法和范围是不同的。在某些方面，它们也可以是互补的解决方案，可以一起使用。
关于该方法，HDIV 尝试通过 与网络框架的集成。为了实施这种方法，HDIV 已集成到一些最常用的 Java/JVM Web 框架中，例如：Spring MVC、Grails、JSF、Struts 1、Struts 2. 重要的是要注意，如果您的应用程序使用 web 框架标签来呈现链接和表单，HDIV 不需要在源代码中进行任何更改，只需一个声明性配置（XML 或 Java 基于配置的配置).
另一方面，ESAPI 提供了开发人员必须在其源代码中使用的许多实用程序 (APIs)。换句话说，程序员必须在他们的源代码中手动包含所有这些实用程序。 ESAPI 不依赖于 Web 框架，可以在任何 Web 应用程序中使用，因为它没有与 Web 框架集成。
关于范围，HDIV 不涵盖 ESAPI 提供的一些功能，也仅限于支持的 Web 框架。重要的是要注意，其中一些功能已经包含在 Web 框架（Struts、Spring MVC 等）或 Spring 安全性：
等解决方案中- 身份验证和会话管理：由应用程序服务器涵盖 和 Spring 安全性
- 输出编码：由网络框架标签覆盖（在这种情况下Spring MVC）来避免 XSS（转义函数）。不包括其他类型的编码，例如避免 SQL 注入的编码。
- 加密函数：Spring 安全性涵盖 (http://docs.spring.io/spring-security/site/docs/3.1.7.RELEASE/reference/crypto.html) 或 ESAPI。我没有比较这两个框架，但看起来它们 相似。
- 特定于参数的输入验证：涵盖所有 Web 框架 （Struts、Spring MVC 等）
HDIV 旨在补充 Java EE、Spring 安全和 Web 框架提供的安全功能。
为了更深入地了解 HDIV 和 ES 之间的区别API 我将尝试比较这两个框架的功能以涵盖 OWASP 十大网络风险。我已经将 ESAPI 2.x 和 ESAPI 3.x 中包含的功能包含在 github (https://github.com/ESAPI).
A1- 注入：
- HDIV：关于 HTTP 参数值、url 和 cookies HDIV 减少 此漏洞的风险仅来自文本的数据 表单中的字段，对其余部分应用完整性验证 来自客户端的数据（确保接收到的值是 与服务器端生成的相同）。对于包含的文本字段 在表单中，HDIV 提供通用验证（白名单和 黑名单）以避免注入攻击。
- ESAPI：每个参数的手动输入验证。这个功能很有用 但几乎所有的网络框架都已经提供了。除此之外，SQL 编码功能可在之前以编程方式对 SQL 进行编码 查询执行。
A2-损坏的身份验证和会话管理：
- HDIV：不提供针对此 Web 风险的功能。我们推荐 使用 Spring 安全性进行身份验证和应用程序服务器 用于会话管理的功能（Servlets 规范）。
- ESAPI：提供必须以编程方式使用的实用程序 程序员。
A3-XSS：与A1相同，但在这种情况下可以避免XSS风险。
- HDIV：关于 HTTP 参数值和 URL HDIV 降低风险 此漏洞仅适用于来自文本字段的数据 在表单中，对其余数据应用完整性验证 来自客户端（确保接收到的值与 在服务器端生成）。对于表单中包含的文本字段， HDIV 提供通用验证（白名单和黑名单）以便 避免注入攻击注入攻击。 HDIV 不包括任何 输出编码功能并将此责任委托给网络 框架标签，在本例中为 Spring MVC。
- ESAPI：包括每个参数的手动输入验证。这个功能是 很有用，但几乎所有 Web 框架都已经提供了。还提供输出 输出编码的编码特征。程序员必须在源代码中使用此编码器。
A4-不安全的直接对象引用：
- HDIV：控制服务器端生成的所有数据（由 框架标签）确保数据的完整性并消除 这种风险。不需要在支持的范围内更改任何源代码 网络框架。重要的是要注意 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-敏感数据暴露：
- HDIV：提供保密功能以隐藏 HTTP 的值 参数。 HDIV 不提供任何加密 API.
- ESAPI: 提供加密 API 来加密、解密等。 更多 详细信息：https://github.com/ESAPI/esapi-java-legacy/blob/master/documentation/esapi4java-core-2.0-crypto-design-goals.doc。 此功能包含在 ESAPI 2.x 中，但我没有在其中找到 ESAPI 3.x.
A7-缺少功能级别访问控制：
- HDIV：感谢 HDIV 实施的完整性验证， 避免利用此 Web 风险并限制使用仅 URLs 先前由服务器生成，保持原始合约 由应用程序提供。
- ESAPI：提供了一个 API 以编程方式实现它。据我所知 知道它类似于 Spring Security 提供的功能 程序员必须在源代码中使用它来保护每个 URL.
A8-跨站请求伪造 (CSRF)：
- HDIV：为每个表单添加随机标记以避免此漏洞 感谢 HDIV 与 Web 框架表单标签的集成。
- ESAPI：提供一个API来生成令牌。此令牌必须由 程序员手动处理每个 Web 表单。
A9-使用具有已知漏洞的组件：
- HDIV：不包括特定功能，但谢谢 HDIV 在许多方面对用户施加的交互限制 cases 无法利用已知漏洞。
- ESAPI：我没有在文档中看到任何功能，但我不是 ES专家API.
A10-Unvalidated redirects and forwards：该漏洞主要与不可编辑数据或之前在服务器端生成的数据的操作有关，与A4非常相似。
- HDIV：控制服务器发送的所有数据，不允许 重定向到恶意网站。
- ESAPI: ESAPI提供的解决方案将与提供的相同 对于必须在源中使用的 A4 (AccessReferenceMap) 代码。
Roberto Velasco Sarasola（HDIV 队）