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-te...