我正在尝试通过使用 lombok extern Slf4j 记录它来获取异常详细信息。但是在覆盖率扫描中发现了一个问题，如下所示。
这是一个安全审计发现。CID 227846（第 1 个，共 1 个）：日志注入 (LOG_INJECTION)。受污染的字符串 ex 存储在日志中。这可能允许攻击者伪造日志消息以混淆自动日志解析工具或试图诊断攻击或其他问题的人。该值在字节码中使用不安全，无法显示。可以通过验证用户可控输入是否符合预期来解决日志注入漏洞。
log.error(Constants.EXCEPTION_OCCURRED_MSG, ex);
我很少找到解决此问题的选项。ESAPI 或 Apache log4j 审计是否适合此处。请建议。
对于 Apache Log4J Audit，我不能说太多，因为我从未看过它（尽管 20 秒浏览其主页似乎表明它更多的是尝试结构化日志消息，然后 SIEM 将知道如何解析，而不是进行过滤/编码/等的任何类型的“安全”日志记录）。至于 ESAPI，虽然 ESAPI 确实在某种程度上处理了“安全日志记录”，但 IIRC（没有验证）它确实对异常没有多大作用. 主要是 ESAPI 的日志记录信任异常堆栈，更关注错误消息本身。通常对于安全设计，除非经过验证，否则绝不应将用户数据放在异常消息中。但是这种验证不是一般的日志框架可以做到的。对于日志框架，它必须能够处理任何Exception（或者可能是ThrowableYMMV）和任何字符串，并且当它到达日志框架时，特定的上下文是应该如何验证的内容已经丢失。
ESAPI 的“安全日志”主要包括将“\r”或“\n”字符作为记录的“消息”字符串的一部分（不是异常）替换为“_”（以防止日志注入），并可选择进行 HTML 实体输出编码在消息上（以防有人打算在浏览器中仔细阅读日志消息；目的是防止通过日志消息进行 XSS 攻击）。尽管您可以通过足够的努力将其扩展为做其他事情（例如，过滤掉 ESC 序列等）。
最终，为了完全防止日志注入攻击，您必须在记录之前验证所有不受信任的数据。ESAPI 的Validator可以帮助您，但作为开发人员，您仍然需要在适当的时候使用适当的验证标准调用它。
201 年 12 月 29 日添加：就使用 ESAPI 而言Validator，我并不是要使用 ESAPI 进行输出编码Encoder。相反，您将创建一个正则表达式来将您的预期数据列入白名单，并将其放入您的validation.properties中，然后调用其中一种Validator.getValidInput()方法。如果您没有被ValidationException抛出，根据您的正则表达式，输出应该是“安全的”。（请注意，您可能需要在多个地方使用许多不同的正则表达式来执行此操作。）OTOH，我不能保证会让您的 Coverity 扫描满意，因为它不可能知道您提供的正则表达式是否是一个合适的或不合适的。（我也不认为它会做那么深入的数据流分析以认为它是“安全”的。）
我想我需要更多关于该错误到底在寻找什么的详细信息。例如，如果担心与“ex”相关联的异常消息包含 PII 或其他可能记录的敏感信息，那么除非您可以控制引发的异常，否则这将更加困难。OTOH，如果控件正在插入攻击者，则可以插入类似 Log4shell 漏洞的东西，该漏洞攻击了自 2013 年以来（显然）没有人意识到正在发生的不安全反序列化，这不是可以轻松防御的东西，如果有的话，因为问题是在底层的日志系统中，用于类似的东西。通常，解决此问题的最佳方法是与安全审计员交谈并具体询问他们他们会考虑对此进行补救。那是他们期望的什么样的清理或验证？此外，您应该了解，在获得管理层批准后，您通常可以在某处记录风险，然后决定“接受”。帮助您的管理层了解大多数“日志注入”漏洞并不像我们最近看到的一系列 Log4J 2 漏洞那样严重。只是在过去一个月左右的时间里，Log4Shell 漏洞让每个人都处于紧张状态。如果您决定接受风险，您可能希望在定期审查的“风险登记册”中对其进行跟踪，但您也希望在审计工具中将其标记为“已接受风险”。
在我自己不知道更具体的细节的情况下，恐怕我无法给你更具体的答案。我愿意尝试在不同的论坛中提供更多帮助，让我的 ESAPI 同事参与进来。特别是对 ESAPI Logger 进行了重写的 Jeremiah Stacey 可能有一些想法，但我认为他不会监控 SO，因此电子邮件可能是一个更好的开始论坛。
希望有点帮助。-凯文