包装或不包装ESAPI

Question

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

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

但是，当我们确定接口中需要的方法时，它看起来越来越像ESAPI本身使用的接口。而ESAPI本身就是一个门面，具有Validator、Encryptor等的可配置实现。

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

Answer 1

好吧，虽然我原则上同意整个"ESAPI is be be the wrapper“的说法，但我认为你总是需要考虑更广泛的问题。首先，也是最重要的，这可能取决于您打算使用多少ESAPI，以及它在源代码中的分布范围有多广。如果你只打算在一些孤立的代码中使用它的一小部分，那么用另一个层包装它可能是没有意义的，因为如果需要的话，改变它将是相对简单的。另一方面，如果您处于另一个极端，保护您的投资并将其与未来的任何更改隔离开来可能是一个好主意。(例如，提议的ESAPI3(请参阅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编码器项目和OWASP Java HTML Sanitizer项目。(对不起，我手头没有链接，但我相信你和我一样知道如何使用搜索引擎。)

-kevin wall / ESAPI Java项目负责人

Answer 2

ESAPI的目标是be The wrapper，允许您在您认为合适的时候交换组件。然而，在它目前的版本中，这并不是一个可行的方法，因为ESAPI占用了很大的空间，坦率地说，大多数人只使用了ESAPI的一小部分。

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

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

Answer 3

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

但是我使用ESAPI已经有一两年了(仅用于输出转义)，直接使用这个库没有任何问题。

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

如果你对在接口后面提取有更好的感觉，那就去做吧。