CloudLoggerFactory的Sanitized Logger显示了Veracode Scan中的CRLF Injection漏洞

Question

我们使用S4 SDK的CloudLoggerFactory来记录整个应用程序中的异常。 对于“SampleClass”类，我们创建一个这样的记录器：

private static final Logger logger = CloudLoggerFactory.getSanitizedLogger(SampleClass.class, "(END)");

并将其称为例外e：

    logger.error(e.getMessage(), e);

Veracode扫描显示此日志记录行易受CLRF注入攻击。 据我所知，getSanitizedLogger与“（END）”参数一起解决了这个问题。 你能提供一些有关这个问题的见解吗？

先感谢您！

Answer 1

更新：正如Sander在下面的回答中提到的，我们从SAP Cloud SDK 3.0.0版开始删除了CloudLoggerFactory 。

我们的理由是，我们无法更改消费者可能在其应用程序中使用的每个库的已使用Logger实现。 这意味着我们无法将下面提到的令牌添加到消费者的所有日志消息中，这极大地降低了其效率。

因此，我们决定放弃CloudLoggerFactory并建议消费者以这种方式配置他的日志记录实现，以便自动添加此令牌。 在此级别上，可以在每条日志消息的末尾都有此令牌，允许对伪造日志进行自动测试。

---

清理过的记录器应该做的是使日志锻造可识别。 为此，它执行以下操作：

• 此记录器具有您提供的类（在您的情况下为SampleClass.class ）作为记录器名称。 此名称将放置在打印输出中，具体取决于记录器实现的配置。 这是SLF4J的默认行为。

• 在使用此记录器创建的每条日志消息的末尾添加(END OF LOG ENTRY) （或您提供的令牌）。 如果在您的日志消息中遇到此令牌，则会替换为(MESSAGE MIGHT BE FORGED!) ，因为这将指示某些输入试图篡改您的日志消息。

这两个属性都允许您识别日志消息是否实际有效或是否通过Log Forging创建。

要查看以下示例，首先使用“unsanitized”记录器：

final Logger logger = CloudLoggerFactory.getLogger(SampleClass.class);

logger.error("Some valid first message");
logger.info("Something still valid\n[main] ERROR very.important.class Major Database Error!");
logger.error("Some valid last message");

在我的机器上，输出看起来像

[main] ERROR com.sap.sandbox.SampleClass - Some valid first message
[main] INFO com.sap.sandbox.SampleClass - Something still valid
[main] ERROR very.important.class Major Database Error!
[main] ERROR com.sap.sandbox.SampleClass - Some valid last message

因此，没有机会确定这些消息有问题。

因此，如果您使用CloudLoggerFactory.getSanitizedLogger而不是CloudLoggerFactory.getLogger则会获得以下日志输出：

[main] ERROR com.sap.sandbox.SampleClass - Some valid first message (END OF LOG ENTRY)
[main] INFO com.sap.sandbox.SampleClass - Something still valid
[main] ERROR very.important.class Major Database Error! (END OF LOG ENTRY)
[main] ERROR com.sap.sandbox.SampleClass - Some valid last message (END OF LOG ENTRY)

在这里，您可以看到SampleClass中的一条消息实际上以令牌结尾，但没有一条消息结束。 因此，您可以推断日志中存在一些错误，您需要进一步调查此问题。

对于Log Forging方面来说太多了，这就是消毒后的记录器可识别的实际攻击。

关于CLRF注入问题：此问题在很大程度上取决于创建的日志输出的进一步使用：

• 如果将日志消息存储在数据库中，则需要某种方法来防止SQL注入。
• 如果您使用基于Web的日志分析器查看日志文件，则需要某种方法来阻止XSS。
• ...

如果我们要逃避所有这些潜在的用例，它实际上只是用编辑器读取日志文件，这是最常见的用例，更复杂。

所以你需要决定你的情况是实际问题还是误报。

另一点是，您的所有其他依赖项也需要为您的用例转义其日志消息。 这意味着更简单和最重要的解决方案是在实际的记录器实现上配置它，例如用于Logback： https ：//logback.qos.ch/manual/layouts.html#replace。

Answer 2

实际上我们计划在即将发布的主要版本中删除日志清理功能。

我们得出结论，它实际上给出了一种错误的安全感，并且应该在记录器实现级别上解决，而我们不能在SDK级别上执行，因为我们只依赖于Slf4j抽象。

（免责声明：我是SAP Cloud SDK开发人员之一。）