2017-04-12 179 views
5

我很擔心人們會記錄機密信息服務器日誌。 我已經看到生產中的服務器日誌。有些開發人員意外地記錄了安全相關的信息,如密碼,clientId,clientSecret等。警告日誌記錄安全信息

有沒有什麼辦法像Eclipse插件或任何工具一樣在編寫代碼時提醒開發人員?

`ex : log.info("usernam = " + username + "password = " + password) ;` // 
Warn that confidential info is getting logged. 

我做了一些調查......我已經見過像sonarLint和FindBug

工具,但這些插件還不能解決我的問題。

+2

這樣的事情無法通過工具100%解決,因爲即使您進行靜態代碼分析,只有當您的日誌變量名稱或信息文本實際包含「user」或「password」等子字符串時纔可以使用。如果他們不這樣做,你無法檢測到它。你有沒有聽說過稱爲代碼審查這個有趣的事情?我聽說它是​​有幫助的。 – kriegaex

回答

7

SonarLint提供規則S2068: Credentials should not be hard-coded,該規則的目標是硬編碼憑證的使用,它看起來接近於您嘗試實現的目標,儘管它可能不足以滿足您的需求。

在其他的答案然而,如上所述,識別此類安全漏洞可能最終難以和強大的代碼審查無疑是一個很好的舉措,以降低風險。

現在,如果你真的擔心有關記錄儀的用途,已經知道潛在的問題,並可能泄露哪些數據,我建議編寫自己的Java自定義規則SonarQube。

自定義規則由SonarLint支持,並且可以在企業層面,一旦含自定義插件它部署在SonarQube服務器上應用。該解決方案將允許您明確定義您想要定位的內容,並根據您的需求和企業細節對規則進行微調。編寫這樣的規則並不難,並在以下教程中有記錄:Custom rules for Java

3

有許多不同的方式如何安全漏洞能夠出現。將數據記錄到瀏覽器控制檯只是其中之一。

而且據我所知,沒有任何工具,可以自動檢測這些安全問題。程序員有責任在頁面上不公開私人用戶信息。

在這種情況下,建議是:決不登錄密碼(尤其是未加密的)對瀏覽器控制檯!而是使用無法解密的算法對數據庫中的密碼進行加密。

+2

'加密'你可能意味着'哈希'。但是必須小心,許多常見的散列算法不適用於密碼散列。您應該使用現代散列函數,例如bcrypt。但在這種情況下密碼的存儲方式並不相關,因爲在某些時候用戶必須以明文形式輸入密碼。有些框架可能會幫助您更難直接訪問和記錄密碼。 – Kapep

+1

是的,我的意思是「哈希」。我沒有提供關於特定算法的建議,因爲正如你所說,許多正式被認爲是安全的算法已經不復存在了(而且這個問題已經脫離了這個問題的主題)。 –

0

可能是你應該嘗試的對比工具。它很好,我們已經使用它很久了。

它照顧到所有的更新OWASP十大問題。

相當不錯的企業應用程序中發現的安全漏洞。

他們的支持也不錯。

0

另一種方法是創建一個自定義日誌的appender看起來對某些搬弄是非的模式(例如相當於「密碼」和「passwd文件」)和抹殺的消息,或將引發錯誤。

但是,這可能是危險的。如果壞人知道你這樣做了,他們可能會試圖利用它來掩蓋他們的蹤跡甚至崩潰你的服務器。

1

我不認爲我的呼吸了在這一個部分外的即裝即用的解決方案。除了您自己的日誌記錄之外,您還必須關注由您的依賴關係完成的日誌記錄。也就是說,您有兩個工作領域:進入日誌的內容以及誰可以訪問日誌。

就日誌而言,解決此問題的最佳工具是教育和協作(包括上述代碼評論)。首先編寫一份記錄的非功能性需求清單,其中包括解決記錄什麼和如何記錄的安全性(標記,級別,敏感參數等)。我建議與同事們一起定義這份清單,以便它不會被稱爲「Ravi的伐木運動」而不是「我們真正需要做的事情」。

一旦該列表被定義並且您得到了您的同事和/或管理層的支持,您可以編寫用於記錄實現的包裝器,以支持您組裝的非功能性記錄需求列表。如果確實需要記錄敏感參數,請提供一種參數非對稱加密方式,供以後通過根帳戶進行檢索:例如存儲在只能由root/container訪問的文件中的加密密鑰。對於管理層而言,您可能需要花一些時間撰寫價值主張來描述爲什麼您的計劃對貴公司有價值。

下一步與誰定義您的SLDC的工作 - 確保您的SDLC的變化是外部溝通。讓他們爲您的公司創建一個安全編碼清單,並在其上實施一項內容:所有日誌記錄均使用OurCompanySecureLogger實施。現在你可以開始致力於實施這一舉措。我建議在構建服務器上編寫一個檢查依賴關係,如果它發現直接引用log4j,slf4j,logback等,則構建失敗。

關於另一半問題,請與您的SysOps團隊一起工作定義職責分離的規則。也就是說,軟件工程師不應該訪問正在執行日誌記錄的服務器。如果您現在沒有足夠的人員來支持這個想法,那麼您可能需要發揮創意。