封装或不封装 ESAPI答案

【问题标题】：to wrap or not to wrap ESAPI封装或不封装 ESAPI
【发布时间】：2014-04-30 19:09:41
【问题描述】：

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

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

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

ESAPI 是否足够成熟，可以安全地直接依赖它，还是坚持使用这个包装器是否明智？

【问题讨论】：

是的，这确实是一个基于意见的问题。有一些关于 ESAPI 需要去哪里的讨论，我个人认为它试图做太多......而不是一站式商店，他们应该将它分解成更小的库，然后根据需要导入。我不知道他们定义的接口可能会发生很大变化（不像编码/解码会发生很大变化），但如果我要开始一种全新的方法，我会像你正在做的那样使用适配器模式。 OWASP 不久前剥夺了 ESAPI 的旗舰地位。
从 esapi 贡献者那里得到答案。由于缺乏志愿者，进展似乎停滞不前。 3.0 可能与 2.0 大不相同。将坚持使用包装。

标签： java maintainability decoupling esapi

【解决方案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 Project 和 OWASP Java HTML Sanitizer Project。（抱歉，我没有方便的链接，但我相信你和我一样知道如何使用搜索引擎。）

-kevin wall / ESAPI Java 项目负责人

【讨论】：

谢谢。我喜欢通过 ESAPI 定位器静态访问所有功能。希望看到对该项目重新产生兴趣

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

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

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

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

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

【讨论】：

【解决方案4】：

ESAPI 是否足够成熟，可以安全地直接依赖它，还是坚持使用这个包装器是否明智？

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

这样的小依赖是在单个 java 类中实现的（从 servlet 过滤器调用）：如果接口更改，我们只需更改该类中的几行代码。所以目前包装接口不会给我们当前实现带来任何优势。

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

【讨论】：