ESAPI的目的是什么？

Question

我们使用Veracode静态代码分析来发现和修复代码漏洞。一个反复出现的主题是，他们引用ESAPI作为修复它们的推荐解决方案，例如CW117（如何修复Veracode CWE 117（日志的不正确输出中和））

然而，我真的不明白拥有一个独立的库有什么意义，它只是在其他库之上的某种安全层。如果一个库（如日志API）有漏洞，我为什么要首先使用它？我会为那个特定的开源社区做出贡献并修复那里的漏洞。或者使用另一个可以解决同样问题但已经是我依赖项的一部分的库。然而，像Veracode这样的工具建议使用它，并且在替代解决方案中没有太大的灵活性。

Answer 1

我是另一个ESAPI项目的共同负责人。我将尝试添加一些东西来增加@Lajos Arpad和@avgvstvs提到的信息。

如果有的话，你的抱怨应该是Veracode和Fortify以及其他只推荐ESAPI的SAST工具。这需要那些SAST工具供应商努力让他们的工具从某些漏洞中删除污点标志，因为他们认识到这些库可以正确修复。要做到这一点，工具供应商需要大量的持续投资。

也就是说，对于特定的CWE-117，通常被称为“日志注入”，通常被认为是一个“低”风险漏洞，因此没有很多其他现成的FOSS日志库关心解决它。可以为用于防止日志注入的任何日志库编写自定义附加器。正如Matt提到的，人们甚至可以或多或少地从ESAPI的GitHub repo中窃取这些代码。（ESAPI是根据3条款BSD许可证获得许可的，这是一种非常自由的许可证，因此如果您不想，甚至不必将其退还。）但据我所知，没有其他人费心实现这一点，很大程度上，正如马特解释的那样，这是因为它实际上更像是一个应用程序问题，而不是一个库问题。因此，对于CWE-117的修复，除了ESAPI之外，SAST工具对于Java库可能没有很多其他选项。但对于XSS漏洞等问题，他们至少还应该识别OWASP Java编码器项目。但是如果（比如）Veracode没有做到这一点，您可能需要向供应商提及。

Answer 2

我认为@Lajos Arpad的回答应该被接受，但由于我是esapi项目的联合负责人，我觉得有必要补充我的想法。

然而，我真的不明白有一个单独的库除了作为其他库之上的某种安全层之外什么都不做的意义。

设计模式呢？因此，web应用程序作为一个整体在模型-视图-控制器设计模式下运行，在该模式下，应用程序逻辑被（至少）分为数据层（模型）、表示层（视图）和业务逻辑层（控制器），在其他两部分之间进行中介。这在web上非常成功，因为您的视图是浏览器，模型是RDBMS或NoSQL平台，控制器是服务器上的应用程序代码。服务器代码通常被进一步抽象为一个“ORM”层（想想Hibernate），该层将Java代码转换为SQL代码，然后说，十年前也可能生成视图代码。（想想GWT。）现在，控制器主要是一个RESTful web服务，它处理来自GUI中我称之为“厚客户端”的异步请求。这种MVC抽象已经无处不在，您可能没有意识到这是一种抽象！

至少，这允许您整齐地分离视图的javascript代码、服务器的Java代码，以及模型的数据库或ORM代码。

分离安全层会在控制器逻辑内的应用程序中创建一个单层，允许您作为程序员做出安全决策。但我们通常会进一步区分：控制器通常依赖于服务：这些服务通常是应用程序的多个部分所需要的——所以这里有一个抽象。安全就是其中之一。您还可以定义一个用户服务、一个角色服务，以及表示用户与应用程序交互的任何常见事物。

这引出了另一点。。。

如果一个库（如日志API）有漏洞，我为什么要首先使用它？我会为那个特定的开源社区做出贡献并修复那里的漏洞。或者使用另一个可以解决同样问题但已经是我依赖项的一部分的库。

这是一厢情愿的想法。我过一会儿就会解释原因。

然而，像Veracode这样的工具建议使用它，并且在替代解决方案中没有太大的灵活性。

因为在爪哇岛上没有。有一种付费解决方案称为HDIV。就这样。一些框架将ESAPI集成为一个安全层，如果您只需要输出转义，那么如果您需要使用用户生成的HTML，则可以使用ESAPI编码器项目和HTML消毒器项目。但是日志注入呢？

所以ESAPI有它的缺陷。它是基于单例的。它是单片的。

它提供了比owasp编码器项目更好的编码功能。它提供了一种Antisamy机制来过滤用户生成的超文本标记语言标签。它有一个基于软件的网络应用程序防火墙。（据我们所知，即使有，也没怎么使用。）验证框架是可靠的，并已在其他框架中使用。还有Auth API——据我们所知，它从未被任何人使用过，即使是作为参考玩具应用程序。最后是安全日志记录，这就是你的批评是当之无愧的，并且有很大的吸引力：它基本上是一个包装slf4j的接口，它本身编码到你选择的另一个日志记录实现中。（您将slf4j编码为接口，但在下面交换日志替换。）所以这感觉很粗略，我们在内部开发对话中认识到了这一点。但是（根据我对谷歌5分钟的粗略了解）在2021年没有更好的安全日志功能替代品。在您提到的特定问题——CWE-117——问题过去是，现在仍然不是库，而是将未经验证和未经清理的用户输入直接注入日志的不良做法。ESAPI解决了这个问题，Veracode能够通过对编译后的二进制文件进行数据流分析来解决这个问题。您可以通过复制我们所做的自己实现这一点。代码是免费提供的。

ESAPI最初被设计成一个安全的、紧急的替换库，用于那些刚刚付出最终代价的应用程序——它们被黑客攻击了。因此，尽管您可能只需要一个函数，但单片单例设计将为您提供所有函数。它成为OWASP旗舰产品，事实上选择像Veracode这样的工具主要是一个意外，因为ESAPI是（现在仍然是）唯一提供web安全修复技术的开源java库。我已经描述了其他几个。

当然，至于这个设计是更好还是不同，但现在你可以把时间回溯到2008年，并有事后诸葛亮的自由。（最初的开发人员都没有开发这个库，我和另一个开发人员现在都在维护它。）

Answer 3

让我们有一个共同点。为了实现这一点，我们需要有一些客观条件。因此，我将关注客观优势，而不是“目的”。

有一个保护层可以保护您免受一些安全问题的影响，减少了担心的原因。当然，您可以编写自己的安全保护层，但这很耗时，因此，在许多业务模型中，这不是一个选项。让我们来看一些场景：

你说过你不想使用不安全的库。但是，老板或一些客观的需要可能会迫使你这样做。如果你非常需要尽快实现一些东西，并且需要很长时间来实现它，但是，现有的解决方案可能（！！！）有安全问题，那么你必须使用它们，因为你不知道确切的实现，它可能有一些安全问题尚不清楚，你可能会成为不安全项目意外泄露私人信息的下一个大新闻。

在编写代码时，您有许多担忧。如果您的代码上方没有保护您的代码的层，那么您将不得不不断注意代码可能出现的所有可能的安全问题。

您团队中的一些新开发人员可能会犯一些错误，意外地引入了安全问题，而审查人员的疏忽可能会导致病毒传播。如果没有额外的保护层来防止安全问题，那么您的项目将不受保护。

如果您已经实现了代码，并且在实现时非常安全，那么在某个时候可能会出现一个科学界没有注意到或根本不存在的问题。如果代码涉及敏感信息/资源，则需要定期检查代码，以便在这些新问题可能出现的地方进行重构。如果你的代码上面有一个安全层，那么你可能只需要下载和安装一个新版本，或者，如果它是开源的，偶尔也会贡献一点。

你希望你的人负责防止各种可能的安全问题吗？这是一个相当大的责任，需要大量的知识和大量的时间/精力/金钱。它很可能会失败，因为一个人很难应付一切。相反，也许你可以只处理那些你认为这些工具没有得到应有保护的具体问题，让它们在有效的地方工作。