OneAPM大講堂 | Java 異常日誌記錄最佳實踐

【編者按】本文作者是 Casey Dunham。Casey 是一位具有 10 多年經驗的專業軟體開發人員，以其獨特的方式應對應用安全問題而聞名。本文系國內 ITOM 管理平臺 OneAPM 工程師編譯整理。

作為安全顧問，我對各種應用程式進行評估。 在我測試過的所有應用程式中，我發現它們通常會遇到一些對異常問題的處理和日誌記錄不足。日誌記錄和監控往往是被忽視的領域，並且由於對 Web 應用程式的威脅日益增加，它們已被新增到 OWASP Top 10 的十大問題之一，名為“Insufficient Logging and Monitoring(沒有足夠的日誌記錄及監測)”。

這會帶來什麼問題？讓我們來看看。

日誌?誰需要日誌?

首先，為什麼我們要使用日誌？重點是什麼？

正確的日誌記錄不僅適用於除錯應用程式，而且對取證和事件響應也有許多的益處。您如何知道某人是否正在針對您的應用程式執行漏洞掃描程式？或者正在進行強力攻擊程式試圖訪問使用者帳戶？能知道這些當然最好，但還有其他更微妙的事情。

大多數成功的攻擊都是從攻擊應用程式並尋找其弱點。攻擊者對應用程式進行調查的次數越多，攻擊者可以找到併成功利用該應用程式弱點的可能性就越大。攻擊者之所以能夠保持攻擊是因為其攻擊被忽視了，並且由於違規檢測平均週期 191 天，日誌通常是我們能看到攻擊正在發生的唯一方式了。沒有日誌資訊的話，我們將很難評估誰在什麼時候訪問以及訪問的深度。

建立並遵循日誌記錄策略

我很少見到一個具有實際日誌記錄策略的應用程式。 大多數情況下，我們實施日誌記錄已經是問題出現後的做法了。 我想這可能也算一種策略，但我們能做得更好嗎? 我想我們可以。

當您將日誌記錄新增到應用程式中時，最好有一個總體一致的策略。 儘可能在所有應用程式中使用相同的日誌記錄框架。 這樣就可以實現輕鬆地共享配置，如訊息格式，並採用一致的日誌記錄模式。什麼情況下需要記錄出現警告/錯誤以及要使用哪些日誌記錄級別需要有一致的準則。 在記錄任何東西時，訊息格式應至少包含時間戳，當前執行緒識別符號，呼叫者標識和原始碼資訊。 所有現代日誌記錄框架都支援這種型別的資訊。

將所有這些作為開發人員文件的一部分，這將是在所有業務應用程式中建立和維護日誌記錄的絕佳方式。

記錄完整的堆疊跟蹤

在我所做的許多安全程式碼預覽中，我經常看到的一個錯誤是：不記錄整個堆疊跟蹤以用於查詢異常。 以這個假設為例，這是我多次看到的一個典型錯誤模式：

這個例子有好幾個問題，我們只關注處理 SQLException 的部分。 比方說，在生產中看日誌時，我們看到了這個：

這並沒有告訴你很多資訊。 什麼導致了 SQLGrammarException？記錄器會把所有包含丟擲物件的異常進行歸類，並且寫出堆疊蹤跡。 通過稍微改變程式碼，我們就能更清楚地瞭解發生了什麼：

用這個程式碼我們就能完整的記錄堆疊跟蹤了，記錄清楚地顯示了一些邪惡的活動正在悄悄進行。

現在，只要檢視日誌，我們可以立即看到問題所在。 有人試圖用 Acme’來查詢客戶，並打破了我們的 SQL 語句。 這個異常明確顯示了 SQL 注入，如果我們分析日誌時只能看到原始訊息，這就很容易被忽略。 我們很可能沒有深入考慮這個問題並轉向了其他問題，導致沒有發現這個嚴重的缺陷。

記錄所有異常

“吞噬”異常是我看到的另一個很常見的問題：在應用程式的某個地方丟擲一個異常，開發人員打算用 catch 塊來處理，但由於某種原因，開發人員忘記了它或者認定它不重要。 以下示例說明了此問題：

據我的經驗，這種做法非常普遍並且值得一提。 記錄異常，重新丟擲異常，或者根本不處理異常，在日誌中都不會顯示應用程式出現了任何問題。 我們沒有理由不記錄異常。“吞噬”這樣的異常會導致隱藏在底層的問題被忽視，最終導致業務邏輯或安全漏洞問題。

不要將異常返回給使用者

在執行任何型別的安全評估時，每一條有關應用程式或其環境的資訊都可能有用。 看似無害的錯誤資訊可能正是顧問(或攻擊者)所需要的。 顧問們可能找到您的系統的一個漏洞-對系統進行攻擊或者大大減少有效負荷，如果錯誤資訊揭示相關漏洞正在使用的資料庫系統的資訊，那麼我們需要對這個漏洞進行 SQL 注入測試。

通過某種錯誤處理簡單地向使用者返回異常訊息也是一種常見的做法。 在測試身份驗證系統時，我遇到了很多問題，如以下螢幕截圖所示：

處理這個問題的程式碼可能會這麼做：

稍後，異常會被丟擲並被捕獲。 開發人員用異常資訊編寫傳達給使用者的報錯資訊，這導致使用者能夠看到系統原始的異常資訊。

就異常處理而言，這不僅是不好的做法，而且還會開啟使用者帳戶驗證的應用程式。 根據您正在處理的應用程式的型別，這本身可能就存在風險。

切勿將異常物件的內容返回給使用者。 捕獲異常，記錄它並返回一個通用響應。 隨著程式碼的進化，您永遠不會知道異常訊息可能包含哪些資訊，並且異常訊息本身是否會在將來發生變化。

不要記錄敏感資訊

我提到日誌不僅可用於除錯，還可用於合規性，審計和取證。 由於日誌有很多用途，並且我們傾向於“記錄所有內容”，它們可以成為驚人的資訊來源。 如果日誌包含使用者名稱，密碼，會話令牌或其他敏感資訊，它確實減少了攻擊者的工作量。 日誌將揭示應用程式的內部工作和失敗，攻擊者可以使用這些進一步攻擊應用程式。 因此，我們需要謹慎的對待日誌並將其安全儲存起來。 不應被記錄資訊如下：

• 信用卡號碼
• 社保號碼
• 密碼

但以下型別的資訊也不應被寫入日誌中：

• 會話識別符號
• 授權令牌
• 個人姓名
• 電話號碼
• 使用者選擇退出的資訊(例如，不跟蹤)

還有一個問題：一些司法管轄區不允許跟蹤某些資訊，這樣做違反了法律。 瞭解應用程式的合規性要求及其處理的資料非常重要。

別讓自己身處黑暗之中

雖然日誌記錄不是一項複雜的任務，但在正確使用日誌方面有很多微妙之處和平衡點。 太少的資訊沒有太大價值，但是如果處理不當，太多的資訊有可能變成負擔。

記錄應用程式日誌不是選擇題， 沒有足夠的日誌，你將身在黑暗之中。

OneAPM Li** 智慧日誌分析平臺可以實時收集資料中心基礎架構及應用的海量日誌，實時搜尋，實時分析，洞悉日誌價值。想閱讀更多技術文章，請訪問 **OneAPM 官方技術部落格。 來源：http://blog.oneapm.com/apm-tech/810.html