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開發人員之一。）