如何在JAR文件中實現安全數據庫連接？

Question

我不是Java開發人員，但我的客戶已經雇用了一個更新其網站上的一些JAR文件。 在此之前，我們審核了現有代碼並發現了許多安全漏洞。 我們用於使文件更安全的解決方案之一是創建一個對數據庫具有只讀訪問權限的新數據庫用戶，並且僅針對JAR文件需要運行的那些表。 然后我發現他們將這些憑證與JAR文件一起存儲在純文本文件中，只是遠離公眾的教育猜測。 最后，今天他們要求更寬松的數據庫權限，但我不認為她理解她真的不應該為正確編寫的JAR文件需要它們。

無論如何，我很確定這個開發人員如果把它咬在后面就不會知道安全漏洞。 而且我對Java / JAR文件不夠了解，不能正確地告訴她她應該做什么，只關於infosec告訴她她不該做什么。

那么在編寫連接到遠程MySQL數據庫的分布式JAR文件時，典型的安全注意事項是什么？ 是否有加密連接詳細信息（用戶名和/或密碼）的標准方法？ IIRC，不是.jar文件只是美化ZIP檔案，並且沒有任何人可以解壓縮文件並查看源代碼中的連接細節？ 有沒有辦法加密jar文件內容？

---

更新：我收到了開發人員的以下說明。 這聽起來不錯嗎？

jar文件中的所有類都是加密的。 我總是加密所有類文件，然后將它們存檔在一個jar文件中。 如果您打開任何[編輯] jar，您將只看到加密代碼。 因此，用戶無法通過反編譯來查看源代碼。 這些類確實使用jdbc連接到db，搜索eangine需要連接到DB才能運行sqls。 這些sql是jar文件中的加密clase。

當我問你關於加密數據庫密碼時，我的意思是你在下面說的。 我們將在java中編寫加密/解密代碼並使用它。 來自此源代碼的編譯類將再次作為reoutine類加密過程的一部分進行加密。 我們使用名為Retroguard的Java混淆工具來加密所有類。 我們還在html頁面中嵌入了一個密鑰，以確保只有在[編輯]網站下載后才能使用該應用程序。 如果用戶將jar復制到他的本地計算機並嘗試運行它，它將失敗。

Answer 1

是的，JAR只是ZIP文件，因此完全可以使用WinZip打開它並查看內容。 如果您知道自己在做什么，可以在里面找到明文密碼。

聽起來您的JAR包含直接連接到數據庫的客戶端。 您沒有說這是通過Internet還是VPN或LAN完成的。 數據庫是從客戶端遠程部署的嗎？

這就是客戶端/服務器應用程序消失的原因之一：很難通過Internet保護它們。

您的應用聽起來像我的經典客戶端服務器。 我有這個權利嗎？

通常在客戶端和數據庫之間引入中間層以檢查安全性，驗證和綁定輸入，以及將請求傳遞到適當的處理程序以進行實現。 讓用戶在將中間層傳遞給數據庫之前提供中間層必須驗證的憑據。

它還可以為您提供針對SQL注入攻擊的戰斗機會。

如果加密JAR內容，則必須編寫自定義類加載器以在加載時對其進行解密。 不適合膽小的人。

如果您的客戶端是Swing應用程序，並且為每個組件注冊了監聽器和事件處理程序中內置的所有邏輯和數據庫內容，那么您將手上有一個嚴重的重寫。 您將轉向更多面向服務的體系結構，其中所有工作都由服務器端的服務完成。 客戶端只在經典MVC中執行它應該做的事情：將事件傳遞到服務器端並顯示結果。 您的客戶將更輕松。

這將是您的開發團隊和業務的最大沖擊。

Answer 2

我將通過陳述經常陳述的內容開始我的回答：“任何人都可以創建一個他/她無法破解的安全計划”。

現在，注意在同一更新中提及加密和混淆的更新，明智的是要注意加密與混淆不同。 從技術上講，加密涉及使用密鑰將一些明文轉換為密文，明文只有在知道原始密鑰的情況下才能恢復。 根據定義，混淆與加密無關 - 它涉及從可執行源代碼中刪除信息，這使得可執行文件被認為“難以”進行逆向工程。 通常，混淆涉及用較小的符號替換符號，有時重新排序使反向工程源代碼難以讀取的源代碼，同時保留原始的執行配置文件（混淆的源代碼具有相同的代碼和數據流路徑）作為原始）。

這里重要的是密碼被編碼到源代碼中。 假設混淆的源代碼還包含硬編碼密碼是合理的。 這個假設是合理的，因為大多數混淆器從未試圖改變類文件中的常量池 - 改變常量池是危險的，因為它可能導致運行時行為的改變。 如果密碼已經作為字符串硬編碼到源代碼中，那么類文件（模糊或未模糊）將在字符串常量池中具有密碼，該密碼將由JVM加載到內存中（沒有解密或解碼）之間的過程）。

這種情況下的最佳實踐是讓最終用戶指定數據庫用戶ID和密碼（如果他們正在管理應用程序設置），以安全地存儲這些用戶提供的憑據（這取決於應用程序的性質; Java EE應用程序應嘗試讓容器管理這些憑據），並在從安全存儲中檢索這些憑據時安全地管理這些憑據。 您可能需要查看有關不安全存儲的OWASP文章以獲取更多指示。

鑒於使用applet，建議不要在applet中使用數據庫用戶ID和密碼。 這需要由於各種原因而完成 - 良好的應用程序允許僅通過對應用程序的配置更改來更改數據庫用戶ID和密碼。 在源代碼中對密碼進行硬編碼勢必會增加管理開銷; 每次DBA選擇更改密碼時，您可能必須讓最終用戶清除其Java小程序緩存（這有時會在理智的數據中心中發生）。 此外，在部署對applet的更改時，您可能還需要防止數據庫帳戶鎖定。 與發布的其他建議一樣，從中間層管理數據庫連接將具有很大的商業意義。

Answer 3

我認為大多數開發人員對此類事情的約定是將配置文件存儲在Web目錄的根目錄之外。 當然，如果這是一個桌面應用程序，而不是不可能的網絡。 我之前在基於SWING的MySQL驅動應用程序中使用有限數量的用戶所做的事情不是使用中間層進行身份驗證並使用MySQL的內置身份驗證將數據呈現為服務，因此所有安全性都將在架構，然后為每個用戶復制權限設置。 一種hackish但可靠的方法。

Answer 4

用純文本說（我認為）是非常脆弱的。 實際上，人們可以提取jar並閱讀該純文本中的內容。

如果使用jar是必須的，我建議創建一個類（只是一個簡單的類），其中包含帶有final關鍵字的用戶名，密碼，url等。 即使這種方法不是很安全，但至少不能輕易讀取編譯的類。 另一個優點（或可能是缺點）是“硬編碼”連接屬性不容易修改。 即使你有源代碼，你仍然需要重新編譯它並重新jar它。