HDIV和ESAPI之间的区别
我计划使用Spring MVC开发一个Web应用程序，并试图弄清楚哪个是最好的库，用于超过10大OWASP问题。 我来看两个HDIV和ESAPI，任何人都可以帮我理解它们之间的区别。
感谢您的帮助。
首先，我认为两种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提供的某些function，也仅限于支持的Web框架。 值得注意的是，Web框架（Struts，Spring MVC，…）或Spring Security等解决方案已经涵盖了其中一些function：
- 身份validation和会话管理：由应用程序服务器和Spring Security覆盖
- 输出编码：由Web框架标签（在这种情况下为Spring MVC）覆盖以避免XSS（转义函数）。 不包括其他类型的编码，如编码，以避免SQL注入。
- 加密function：由Spring Security（ http://docs.spring.io/spring-security/site/docs/3.1.7.RELEASE/reference/crypto.html ）或ESAPI提供。 我没有比较两个框架，但似乎它们是相似的。
- 特定于参数的输入validation：由所有Web框架（Struts，Spring MVC等）覆盖
HDIV旨在补充Java EE，Spring Security和Web框架提供的安全function。
为了更深入地了解HDIV和ESAPI之间的差异，我将尝试比较这些function，以涵盖OWASP十大网络风险与两个框架。 我在github（ https://github.com/ESAPI ）中包含了ESAPI 2.x和ESAPI 3.x中包含的function。
A1-注射：
- HDIV：关于HTTP参数的值，URL和cookie HDIV将此漏洞的风险降低到仅来自表单内文本字段的数据，对来自客户端的其余数据应用完整性validation（确保收到的值是与服务器端生成的相同）。 对于表单中包含的文本字段，HDIV提供通用validation（白名单和黑名单）以避免注入攻击。
- ESAPI：每个参数的手动输入validation。 此function很有用，但几乎所有Web框架都已提供此function。 除此之外，SQL编码function在查询执行之前以编程方式对SQL进行编码。
A2-Broken认证和会话管理：
- HDIV：不提供此网络风险的function。 我们建议使用Spring Security进行身份validation，并使用应用程序服务器function（Servlet规范）进行会话管理。
- ESAPI：提供必须由程序员以编程方式使用的实用程序。
A3-XSS：与A1相同，但在这种情况下避免XSS风险。
- HDIV：关于HTTP参数的值和URL HDIV将此漏洞的风险仅降低到来自表单内文本字段的数据，对来自客户端的其余数据应用完整性validation（确保接收的值相同）作为在服务器端生成的）。 对于表单中包含的文本字段，HDIV提供通用validation（白名单和黑名单）以避免注入攻击注入攻击。 HDIV不包含任何输出编码function，并将此职责委托给Web框架标签，在本例中为Spring MVC。
- ESAPI：包括每个参数的手动输入validation。 此function很有用，但几乎所有Web框架都已提供此function。 还提供输出编码的输出编码function。 编码器必须在源代码中使用此编码器。
A4-Insecure Direct Object References：
- HDIV：控制服务器端生成的所有数据（由框架标签处理），确保数据的完整性并消除这种风险。 在支持的Web框架内不需要任何源代码更改。 重要的是要注意HDIV支持不同的方法来管理重新收集的信息：密码（状态在响应中被加密），内存（状态存储在HttpSession中），哈希（状态的哈希存储在HttpSession中，以及网络响应中的内容）。
- ESAPI：有必要创建一个地图以编程方式包含每个参数并将其存储在会话中。
（ http://www.jtmelton.com/2010/05/10/the-owasp-top-ten-and-esapi-part-5-insecure-direct-object-reference/ ）。 此function包含在ESAPI 2.x中，但我在ESAPI 3.x中找不到。
A5-安全配置错误：
- HDIV：不包含特定function，但不允许访问以前未由服务器发送的资源，从而避免利用意外行为或访问私有资源。
- ESAPI：我没有找到任何function，但我不是ESAPI的专家。
A6敏感数据暴露：
- HDIV：提供机密性function以隐藏HTTP参数的值。 HDIV不提供任何加密API。
- ESAPI：提供加密API以加密，解密等。更多详细信息， 请访问： https ： //github.com/ESAPI/esapi-java-legacy/blob/master/documentation/esapi4java-core-2.0-crypto-design-goals .doc 。 此function包含在ESAPI 2.x中，但我没有在ESAPI 3.x中找到。
A7缺失function级访问控制：
- HDIV：由于HDIV实施的完整性validation，避免了利用此Web风险并限制仅使用服务器先前生成的URL，维护应用程序提供的原始合同。
- ESAPI：提供API以编程方式实现它。 据我所知，它类似于Spring Security提供的function，源代码中的程序员必须使用这些function来保证每个URL的安全性。
A8-跨站请求伪造（CSRF）：
- HDIV：由于HDIV与Web框架表单标记集成，因此添加了一些令牌来避免每个表单的漏洞。
- ESAPI：提供用于生成令牌的API。 程序员必须手动将此标记添加到每个Web表单。
A9-使用已知漏洞的组件：
- HDIV：不包括具体function，但由于HDIV在很多情况下对用户应用的交互限制无法利用已知漏洞。
- ESAPI：我没有在文档中看到任何function，但我不是ESAPI的专家。
A10-未经validation的重定向和转发：此漏洞主要与先前在服务器端生成的不可编辑数据或数据的操作有关，与A4非常相似。
- HDIV：控制服务器发送的所有数据，不允许重定向到恶意网站。
- ESAPI：ESAPI提供的解决方案与必须在源代码中使用的A4（AccessReferenceMap）提供的解决方案相同。
Roberto Velasco Sarasola（HDIV团队）
首先，OWASP的ESAPI不再是OWASP的旗舰产品了：图书馆的主要开发工作停滞不前，2.1版本只是为了修复一个主要的CVE。 看起来常规贡献进入HDIV库。 HDIV还有大量资源演示如何将其集成到通用Web框架中 – 他们的文档涵盖了Spring，Grails，当然它也是从Struts1和Struts2开始的。
HDIV提供了一个讨论其架构的powerpoint 。 虽然我真的不喜欢它说它消除了 XSS（它没有，但不能）基本架构看起来很不错。
在搜索文档时，HDIV似乎唯一缺少的是一种规范化 – 入侵检测方法。 理论上，因为它依赖于对不可编辑数据的哈希，所以你会收到警告，有人试图篡改你的参数。 但是，使用esapi，它会检测多个编码攻击并相应地通知您 – 它会为您提供更好的信息。 （参数名称，用户ID和尝试输入。）
此外，HDIV似乎没有ESAPI提供的几个function：
- 防止对数注入
- 身份validation机制 – >虽然很少使用，但它确实具有比开箱即用的更好的Java安全性实现。 它还具有用户的直观模型。
- 经过良好validation的加密实现 – >如果您想要安全使用Java加密，则已针对ESAPI运行安全评估。
- SQL注入防御可以在（由于某种原因）您不能使用参数化查询或存储过程的实例中使用。
- 特定于上下文的输出编码。 虽然由于ESAPI目前收集灰尘的状态，如果你需要编码，我会用它代替。 。 重要的是要注意，正确的输出转发比任何输入过滤/validation都要好10M倍。 您可以跳过WAF并仍然具有出色的安全性。 反向陈述是错误的。
- 细粒度控制参数特定的输入validation。 WAF方法只标记通用字段类型，并对规则类型应用一个规则适合所有方法。 通过使用
validation.propertiesESAPI可以让您获得所需的细粒度。