如何解决java spring引导应用程序中的安全审计查找日志注入问题

Question

我试图通过使用lombok Slf4j记录异常细节。但在coverity扫描中发现了一个问题如下。

这是一个安全审计发现。CID 227846 (# 1 )：日志注入(LOG_INJECTION)。受污染的字符串ex存储在日志中。这可能允许攻击者伪造日志消息，以混淆自动日志解析工具或试图诊断攻击或其他问题的人。该值在不能显示的字节码中不安全地使用。日志注入漏洞可以通过验证用户可控输入是否符合预期来解决.

log.error(Constants.EXCEPTION_OCCURRED_MSG, ex);

我很少找到解决这个问题的办法。ESAPI或Apache log4j审计是否适用于这里。请建议一下。

Answer 1

我不能多说Apache审计，因为我从来没有看过它(尽管20秒的浏览它的主网页似乎表明它更多地是一种结构化日志记录消息的尝试，然后Log4J就会知道如何解析，而不是进行过滤/编码/等的任何类型的“安全”日志记录)。至于ESAPI，虽然ESAPI在某种程度上确实处理“安全日志”，但是IIRC (没有验证)实际上在例外情况下做的并不多。主要是ESAPI的日志信任异常堆栈，更多的是关注错误消息本身。通常，对于安全设计，用户数据不应该放在异常消息中，除非经过验证。但是，这种验证并不是一般日志框架所能做到的。对于日志框架，它必须能够处理任何Exception (或者可能是Throwable，YMMV)和任何字符串，并且当它到达日志框架时，特定的上下文是应该如何验证的内容丢失了。

ESAPI的“安全日志”主要包括将"\r“或"\n”字符替换为"_“(防止日志注入)作为日志记录的' message‘字符串(也不例外)的一部分，并可选择对消息执行HTML实体输出编码(如果打算在浏览器中仔细阅读日志消息；其意图是防止通过日志消息进行XSS攻击)。尽管您可以通过足够的努力将其扩展到其他事情(例如，筛选出ESC序列等)。

最后，为了完全防止日志注入攻击，您必须在记录所有不受信任的数据之前对其进行验证。ESAPI的验证器可以帮助您做到这一点，但是作为开发人员，您仍然需要在适当的时候使用适当的验证标准来调用它。

添加了12/29/201：至于使用ESAPI的Validator，我并不打算使用ESAPI的Encoder进行输出编码。相反，您将创建一个regex，用于白色列出您的预期数据，并将其放入您的validation.properties中，然后调用Validator.getValidInput()方法之一。如果没有抛出ValidationException，根据正则表达式，输出应该是“安全的”。(请注意，您可能需要在有许多不同正则表达式的几个地方这样做。)OTOH，我不能保证这将使您的Coverity扫描愉快，因为它不可能知道您提供的正则表达式是否合适。(我也不认为它会做那么深入的数据流分析，认为它使用起来是“安全的”。)

Answer 2

我想我需要更多的细节来说明这个错误到底想要什么。例如，如果担心与“ex”相关的异常消息包含可能被记录的PII或其他敏感信息，则这要困难得多，除非您能够控制抛出的异常。OTOH，如果控件正在插入，攻击者可以插入一些类似Log4shell的漏洞，该漏洞攻击了(显然)自2013年以来没有人意识到的不安全反序列化，这是不容易维护的，因为问题在于底层的日志记录系统中存在类似这样的东西。通常，处理此问题的最佳方法是与安全审计师交谈，并询问他们，特别是，他们将考虑对此进行补救。这就是他们期望的哪种消毒或验证？另外，你应该明白，如果得到管理层的批准，你通常可以在某个地方记录风险，然后决定“接受”。帮助管理层理解大多数“日志注入”漏洞并不像我们最近看到的Log4J 2漏洞那样严重。只是在过去的一个月左右，Log4Shell漏洞让每个人都很紧张。如果您决定接受风险，您可能希望在类似于定期审查的“风险登记册”中跟踪风险，但您也希望在审计工具中将其标记为“接受的风险”。

如果我自己不知道更多的具体细节，恐怕我无法给你一个更具体的答案。我愿意尝试提供更多的帮助，在不同的论坛，我可以让我的ESAPI同事。特别是Jeremiah，他重写了ESAPI日志可能有一些想法，但我不认为他会这样监测，所以电子邮件可能是一个更好的论坛开始。

希望这能帮点忙。-kevin