包装或不包装ESAPI

Question

我们有几个需要ESAPI java库提供的功能的webapp。我和我的同事处于两难境地是否直接使用ESAPI，从而创建了对ESAPI的直接依赖，或者创建了一个抽象调用ESAPI的接口。

通过抽象对库的依赖，我们可以灵活地在需要时轻松切换到其他选项。除此之外，我们还可以定义自己的界面，更有可能满足我们的需求。

但是，当我们在界面中识别出我们需要的方法时，它看起来越来越像ESAPI本身使用的接口。 ESAPI本身就是一个外观，具有Validator，Encryptor等可配置的实现。

ESAPI是否足够成熟，可以直接依赖它，或者坚持使用这个包装器是明智的吗？

Answer 1

好的，虽然我原则上同意整个“ESAPI应该 是 包装”的口头禅，但我认为你总是需要考虑更广泛的问题。首先，它可能取决于您打算使用多少ESAPI以及它可能部署在源代码中的分散程度。如果你只是在一些孤立的代码中使用它的一小部分，那么用另一层包装它可能没有意义，因为如果需要它会变得相对简单。另一方面，如果您处于另一个极端，那么保护您的投资并将其与未来的任何变化隔离开来可能是个好主意。 （例如，拟议的ESAPI 3（见https://github.com/ESAPI/esapi-java）计划具有非常不同的接口。）

最后，虽然我很难说，但最近ESAPI的支持并不是很好。在过去的2 - 3年里，只有我自己和另外一个人为此做出了贡献。事实上，虽然它不是一个完成的交易，但ESAPI很可能会失去其OWASP“旗舰”地位（见http://off-the-wall-security.blogspot.com/2014/03/esapi-no-longer-owasp-flagship-project.html）。除非我们开始招募更多的志愿者，否则甚至有人将该项目标记为“日落”。如果您只想使用ESAPI进行输出编码和数据验证，那么我建议您查看OWASP Java Encoder项目和OWASP Java HTML Sanitizer项目。 （对不起，我没有方便的链接，但我确定你知道如何使用搜索引擎和我一样。）

-kevin wall / ESAPI Java项目负责人

Answer 2

ESAPI的目标是成为包装器，允许您根据需要交换组件。在它当前的发布版本中，这根本不是一种可行的方法，但是因为ESAPI占用空间很大，而且坦率地说大多数人只使用ESAPI的一小部分。

话虽如此，ESAPI 3.0旨在解决这个问题，但我们（ESAPI团队）很难让社区参与到新的工作中。您可以查看ESAPI 3.0的github存储库，该存储库旨在解决注释中描述的问题，并将重点转移到提供所有安全控制的API，而不是尝试成为安全控件本身。

Github：https://github.com/ESAPI/esapi-java

Answer 3

我认为这是基于某种意见的。

但是我使用ESAPI一两年（仅用于输出转义）并且直接使用这个库没有问题。

我在XSL样式表中使用了escape方法，所以我创建了一个包装器，但只是为了更好的访问，而不是封装。

如果你对在界面后面提取它感觉更好，那就去做吧。

Answer 4

  

ESAPI是否足够成熟，可以直接依赖它，或者坚持使用这个包装器是明智的吗？

我的故事是我们一直在使用ESAPI（在从html表单中的用户输入的输入字符串中删除各种注入字符模式之前只进行规范化）两年，直接取决于其界面而没有任何问题。

这样一个小依赖项是在一个java类中实现的（从servlet过滤器调用）：如果接口发生变化，我们必须只更改该类中的几行代码。因此，目前包装界面不会给我们当前实施带来任何好处。

我建议通过查看http://www.ohloh.net/p/owasp-esapi-java等其他来源或直接向ESAPI社区提问来评估项目的成熟度。