3

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

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

并将其称为异常 e：

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

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

先感谢您！

4

2 回答 2

1

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

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

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

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

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

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

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

要查看以下示例，首先使用“未清理”的记录器：

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 注入。
  • 如果您使用基于 Web 的日志分析器查看日志文件，则需要某种方法来防止 XSS。
  • ...

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

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

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

于 2019-02-20T15:40:41.340 回答
1

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

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

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

于 2019-07-12T08:34:04.760 回答