如何解決 java spring 啟動應用程序中的安全審計發現日志注入

Question

我正在嘗試通過使用 lombok extern Slf4j 記錄它來獲取異常詳細信息。 但是在覆蓋率掃描中發現了一個問題，如下所示。

這是一個安全審計發現。 CID 227846（第 1 個，共 1 個）：日志注入 (LOG_INJECTION)。 受污染的字符串 ex 存儲在日志中。 這可能允許攻擊者偽造日志消息以混淆自動日志解析工具或試圖診斷攻擊或其他問題的人。 該值在字節碼中使用不安全，無法顯示。 可以通過驗證用戶可控輸入是否符合預期來解決日志注入漏洞。

log.error(Constants.EXCEPTION_OCCURRED_MSG, ex);

我很少找到解決此問題的選項。 ESAPI 或 Apache log4j 審核是否適合此處。 請建議。

Answer 1

I can't speak much for Apache Log4J Audit because I have never looked at it (although, a 20 second perusal of its main web page seems to indicate it is more an attempt at structured logging messages that SIEMs would then know how to parse,而不是進行過濾/編碼/等的任何類型的“安全”日志記錄）。 至於 ESAPI，雖然 ESAPI 確實在某種程度上處理了“安全日志記錄”，但 IIRC（沒有驗證）它確實對異常沒有多大作用。 主要是 ESAPI 的日志記錄信任異常堆棧，更關注錯誤消息本身。 通常對於安全設計，除非經過驗證，否則絕不應將用戶數據放在異常消息中。 但是這種驗證不是一般的日志框架可以做到的。 對於日志框架，它必須能夠處理任何Exception （或者可能是Throwable ，YMMV）和任何字符串，並且當它到達日志框架時，特定的上下文是應該如何驗證的東西丟失了。

ESAPI 的“安全日志”主要包括將“\r”或“\n”字符作為記錄的“消息”字符串的一部分（不是異常）替換為“_”（以防止日志注入），並可選擇執行 HTML 實體 output 編碼在消息上（以防有人打算在瀏覽器中仔細閱讀日志消息；目的是防止通過日志消息進行 XSS 攻擊）。 盡管您可以通過足夠的努力將其擴展為做其他事情（例如，過濾掉 ESC 序列等）。

最終，為了完全防止日志注入攻擊，您必須在記錄之前驗證所有不受信任的數據。 ESAPI 的Validator可以幫助您，但作為開發人員，您仍然需要在適當的時候使用適當的驗證標准調用它。

Answer 2

我想我需要更多關於該錯誤到底在尋找什么的詳細信息。 例如，如果擔心與“ex”相關的異常消息包含 PII 或其他可能記錄的敏感信息，那么除非您可以控制引發的異常，否則這將更加困難。 OTOH，如果控件正在插入攻擊者可以插入類似 Log4shell 漏洞的東西，該漏洞攻擊了自 2013 年以來（顯然）沒有人意識到正在發生的不安全反序列化，這不是可以輕松防御的東西，如果有的話，因為問題是在底層的日志系統中，用於類似的東西。 通常，解決此問題的最佳方法是與安全審核員交談，並具體詢問他們認為對此有何補救措施。 那是他們期望的什么樣的清理或驗證？ 此外，您應該了解，在獲得管理層批准后，您通常可以在某處記錄風險，然后決定“接受”。 幫助您的管理層了解大多數“日志注入”漏洞並不像我們最近看到的 Log4J 2 漏洞字符串那么嚴重。 只是在過去一個月左右的時間里，Log4Shell 漏洞讓每個人都處於緊張狀態。 如果您決定接受風險，您可能希望在定期審查的“風險登記冊”中對其進行跟蹤，但您也希望在審計工具中將其標記為“已接受風險”。

在我自己不知道更具體的細節的情況下，恐怕我無法給你更具體的答案。 我願意嘗試在不同的論壇中提供更多幫助，讓我的 ESAPI 同事參與進來。 特別是對 ESAPI Logger 進行了重寫的 Jeremiah Stacey 可能有一些想法，但我認為他不會監控 SO，因此 email 可能是一個更好的論壇。

希望那些對你有幫助。 -凱文