用日志與監控構建安全的應用程序

　本篇文章根據作者多年來對數百萬行代碼執行安全分析，得出了在應用層日志方面的脆弱現狀。文章討論了在應用程序的安全方面，日志常常被忽略，並證明了應用程序通過實時的安全檢查可以獲得許多好處。文章提出了一個可操作的執行思路，並提供了相關的風險和成本分析。

　　應用程序安全的推動力

　　開發人員與安全人員開始重視安全編程的實踐，實際上，IT廠商也正在利用這個趨勢來向用戶保證應用程序與基礎設施的安全性。然而不幸的是，許多人認為訪問控制和加密差不多囊括了應用程序安全的全部領域。

　　實際上，一些其它的領域也包含在應用程序安全中。OWASP Guide是識別這些領域的一個很好的出發點。工業界的開發小組對OWASP-identified領域有著不同的認識。例如，大部分開發者都已經認識到他們不能開發自己的加密算法，然而很少人意識到用偽隨機數產生器（例如java.util.Random）產生Session IDs所帶來的問題。另外一個被很多人忽視的特別領域就是日志與監控。

　　檢測應用層的攻擊

　　在一個典型的企業環境下，幾乎很少應用程序內置了檢測並通知潛在惡意行為的功能，相反，這些軟件依靠基礎設備，如防火牆，來執行這個功能。但是，不可避免地會存在一些攻擊，它們可能繞過設備的保護機制：例如，來自內部網絡的拒絕服務攻擊，或者繞過客戶端的驗證並被企業網絡認為合法流量的攻擊。當然阻止其中的一部分攻擊是網絡層的入侵檢測系統和入侵阻止系統的任務，但是隨著網站服務的出現、內部網絡和網絡邊界合作訪問的發展，單獨的IDS/IPS系統可能不足以檢測出這些攻擊。

　　當然，為每個應用程序定置一個入侵檢測引擎，這是不切實際的。實際上，這種配置入侵檢測引擎的方法與應用程序安全的原則相矛盾：“要安全地編程，而不是另外再編寫一個安全工具”。一種更可行的辦法是：使用一個日志文件分析引擎來實時地讀取日志文件，運用智能的規則來查找攻擊模式。這類工具已經存在，如Sawmill和Network Intelligence，它們並不是為某個特定的應用程序日志文件分析而設計，通過配置，它們能滿足多個應用程序的需求。本文並不深入討論這些工具；本文的重點是如何使應用程序符合這些工具的要求。大多數應用程序缺乏的是用標准的格式和協調的方法來記錄日志，使得分析引擎能夠從日志文件中提取有用信息。

　　實例一：應用程序中的認證日志

　　許多應用程序，包括那些符合CMM Level 5組織的應用程序，都在使用並不協調的日志模式。下面的例子展示了一個Java程序通過Log4J來記錄非法驗證請求的過程。需要注意的是，在C#.Net領域，這個例子必須采用Log4net而不是Log4J。本文假設已經在使用一些日志工具，如何配置和部署這樣的工具在此並不作討論。

　　if (!request.password.equals(result.password))

　　 { //user supplied wrong p/w

　　 log.debug("Invalid access attempt for " + request.usernane + "

　　 with password " + request.password);

　　...

　　同一個應用程序在用戶認證模塊可能采用下面這個不同的接口：

　　if (myRequest.getPassword() != data.getPassword()) {

　　 log.info("Login failed");

　　...

　　除了沒有對密碼進行加密這個明顯的安全漏洞之外，上面的編碼方法還有一些其它的問題：

　　兩個例子采用不同的日志等級（“debug”和“info”）來記錄失敗的認證嘗試。這就意味著每個程序員必須單獨決定一個日志事件的敏感度。當一個程序員認為這是一個調試事件時，另一個程序員可能認為它稍微有些重要於是把它確定為第二級（“log”）日志，這就意味著這些事件將寫到不同日志文件中。對失敗認證嘗試的相關分析將會變得很復雜甚至不可能。

　　兩個例子使用了不同的語法。這將再次歸因於每個程序員在記錄日志時的個人習慣。許多程序員把低級日志當作調試信息的擴展，並不遵循相關的標准。上面的例子僅僅展示了兩個程序員輸出的不同；在實際的應用程序開發中，可能有幾十個、幾百個甚至幾千個程序員都采用他們各自的語法，這將導致分析這些信息會是一個可怕的事情。而且這也無法保證如果日志發生改變，在軟件新版本中這些分析將仍然有意義。