CloudLoggerFactory的Sanitized在Veracode扫描中显示CRLF注入漏洞

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

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

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

因此，我们决定删除CloudLoggerFactory，并建议使用者以自动添加此令牌的方式配置其日志记录实现。在此级别上，可以在每个日志消息的末尾使用此标记，从而允许对伪造日志进行自动化测试。

经过消毒的日志记录器应该做的是使日志伪造可识别。为了实现这一点，它执行以下操作：

• 此记录器使用您提供的类(在本例中为SampleClass.class)作为记录器名称。此名称将放在打印输出中，具体取决于记录器实现的配置。这是SLF4J的默认行为。
• 在使用此记录器创建的每个日志消息的末尾添加(END OF LOG ENTRY) (或您提供的标记)。如果在日志消息中遇到此标记，则会将其替换为(MESSAGE MIGHT BE FORGED!)，因为这表示某些输入试图篡改您的日志消息。

这两个属性都允许您确定日志消息是实际有效的还是通过日志伪造创建的。

要了解这一点，请看下面的示例，首先使用"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的一条消息实际上应该以令牌结束，但没有令牌。因此，您可以推断日志中存在一些错误，您需要进一步调查此问题。

关于日志伪造方面就说到这里，这是经过消毒的记录器可以识别的实际攻击。

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

如果您将日志消息存储在数据库中，则需要某种方法来防止SQL injection.

• If使用基于web的日志分析器来监视日志文件。还需要某种方法来防止XSS.

• ...

• 。

如果我们可以避开所有这些潜在的用例，那么实际上只需要使用编辑器读取日志文件，这是最常见的用例，就会变得更加复杂。

因此，您需要决定对于您的情况，这是一个实际的问题，还是仅仅是一个误报。

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

Answer 2

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

我们得出的结论是，它实际上给人一种错误的安全感，应该在记录器实现级别上解决，这是我们不能在软件开发工具包级别上做的，因为我们只依赖Slf4j抽象。

(免责声明:我是SAP Cloud SDK开发人员之一。)