【51CTO獨家特稿】雖然這種對關鍵數據的簡易訪問已經極大地提高了工作人員的效率，并提高了顧客的購買欲，但它也為關鍵數據庫打開了巨大的風險之門。不幸的是，許多風險是由缺乏資源的開發人員帶來的，他們往往無法得到足夠的時間、金錢、教育以及來自管理人員的支持，因而無法設計開發沒有漏洞的應用程序。

在上述資源無法到位時，開發人員往往會犯這些錯誤：

1、過于相信輸入方法

當今開發人員將數據庫置于風險之中的一種重要方法是，使其應用程序遭受SQL注入攻擊。當開發人員過于相信用戶輸入時，就往往會出現SQL注入漏洞。

如果不對其進行驗證，例如，如果不驗證一個只接受數字的電話號碼字段，開發者就有可能允許黑客對數據庫進行終端訪問。例如，插入到表單域中的單引號有可能過早地關閉應用程序本應實施的合法SQL查詢，從而使攻擊者可以構建并提交新的查詢。

解決這種問題的最好方法之一就是使用參數化查詢。

參數化查詢可以防止攻擊者改變查詢中的邏輯或代碼，并阻止大多數SQL注入攻擊。參數化查詢出現的時間就像數據庫一樣長，它不像安全的其它許多領域，使用參數化查詢也是保障性能和代碼可維護性的最佳方法。

但開發人員不應當停留于此。還要對用戶輸入進行凈化和驗證，因為有時參數化并不可行。即使可行，攻擊者也可以將非驗證的輸入用于其它惡意目的，如跨站腳本攻擊等。

最老套且最糟糕的問題是，不對用戶輸入進行凈化，即在對數據庫運行查詢之前，不剔除用戶輸入中并不需要的字符，例如不移除撇號或分號。

2、數據庫錯誤消息顯示給終端用戶

在應用程序的SQL查詢出現問題時，如果開發人員允許彈出特定的錯誤消息，這也許有助于診斷，但這也向攻擊者提供了一個探查后端數據庫的內部工作機制的很好途徑。

通過得到的數據庫錯誤消息，攻擊者就會了解數據庫的組織結構和應用程序查詢等許多重要信息，從而更容易展開攻擊。

錯誤消息可以泄露關于應用程序連接的數據庫類型、底層設計等的線索。

這種錯誤會為盲目SQL注入攻擊打開大門，所以開發者應當在頁面顯示一般性的錯誤消息而非特定消息。

3、輕率地對待口令

為了圖方便，許多開發者用多種不安全的方法來輕率地對待用戶口令。例如，他們可能將口令硬編碼到應用程序中。

最明顯的數據庫風險之一在于硬編碼口令和存在于配置文件中的口令。這兩種設計選擇都依賴于這種脆弱的安全性，他們假定攻擊者不會訪問這種信息，因而開發者并不關心文件或其中信息的安全性。

同樣危險的還有將口令存放到純文本中的方法，其中包括不對用戶輸入的口令進行哈希，以及并不對哈希加鹽（加鹽：將隨機位添加到哈希中）。

此外，還有不健全的口令管理，沒有將強健的口令認證構建到應用程序中。

4、使所有的連接都是“超級”的

同樣的，許多開發者通過“根”或其它一些超級用戶賬戶來將應用程序連接到數據庫中，從而將數據庫置于風險之中。這通常是一個與硬編碼口令的應用程序有關的問題，這是因為在這些情況下很難實施適當的特權管理。

普通的應用操作很少需要由“超級”特權所許可的訪問，允許應用程序使用超級特權用戶，會為不適當的非授權活動創造機會。所有的應用程序都應當使用最少特權的用戶憑證連接到數據庫。

5、相信存儲過程是SQL注入的解決之道

當今的許多開發人員相信，存儲過程是防止SQL注入的一種可靠方法。

事實上，如果存儲過程自身的代碼中包含漏洞，或者如果存儲過程被以一種不安全的方式調用，它就并不能防止SQL注入。

在存儲過程中可以發生串的連接或并置。即使存儲過程的調用是準備好的語句，如果在存儲過程自身內部構建和執行查詢，它也有可能易遭受攻擊。

6、將調試代碼留放到生產環境中

正如廚師在做完了美味佳肴之后要打掃廚房一樣，開發人員必須在將程序投放到生產環境中之前，必須清理其代碼，以免打開數據庫的后門。導致這種后門最常見的且易被遺忘的要素是遺留到生產環境中調試代碼。

開發人員將后門放到程序中，其目的是為了調試，從而可以直接啟用數據庫的查詢。忘記在生產環境中清除這種調試代碼是愚蠢的，但也是很常見的錯誤。

7、劣質加密

比不使用加密更為糟糕的唯一問題是，錯誤地使用加密，因為這這種加密給企業一種虛假的安全感。

問題存在于細節中，不管是一個哈希函數或是一個加密例程。如果你并不知道如何正確地實施加密，那就將任務委托給一位專家，并且不要過早地將應用程序投放到生產環境中。

開發人員應當謹慎地對待其加密技術方面的技能和技巧。當今的黑客喜歡本地的加密設計，因為這種設計通常很差勁。

本地的加密幾乎不能給有經驗的攻擊者提供什么價值，并且會給企業帶來一種虛假的安全感。

8、盲目相信第三方代碼

使用第三方的代碼可能為開發人員節約大量的時間，但是開發人員不能在測試代碼問題上抄近路，以確保所復制的代碼不會給應用程序帶來易受攻擊的代碼。

開發人員需要理解，自己要為整個應用程序的威脅分析負責，而不僅僅為自己編寫的代碼負責。

同樣地，如果開發者希望限制那些給數據庫帶來風險的漏洞數量，他們就應當使用最新的開發框架。

許多開發人員會使用WordPress、 Joomla或其它類型的應用程序框架，卻沒有用最新的安全補丁保持其最新。許多類似的電腦都易遭受攻擊，應用程序也如此。

9、輕率地實施REST(表述性狀態轉移)架構

表述性狀態轉移（REST）架構可能是一個有用的范例，但太多的工具會直接從數據庫生成REST接口，從而將接口與數據庫的設計架構聯結起來，并可以暴露攻擊者能夠利用的信息。開發人員應當為一系列抽象的應用程序的特定資源類型和資源的適當操作設計REST接口，而不是把接口直接設計到物理的數據表和非特殊操作。

10、隨處亂放備份的數據庫副本

許多開發人員常常被責怪沒有在測試環境（在其中，開發者尋求測試其應用程序的可選方式）中使用動態數據。不幸的是，這些編碼者的許多人會轉向備份數據庫。

網站可以很好地保護動態數據庫，但是否同樣保護好了自己的數據庫備份呢？在備份中，一周前的數據可能和動態數據一樣具有破壞力，開發者可能會使用備份來針對生產性數據測試其工作，所以開發環境必須小心地遵循生產環境中的安全標準。安全策略應當為數據的所有副本負責，而不僅僅是在線副本。

【編輯推薦】