如何斬斷SQL注入式攻擊的瘋狂魔掌？
近年來，SQL注入式攻擊一直如幽靈般困擾著眾多企業，成為令企業毛骨悚然的夢魘。從八月中旬以來，新一輪的大規模SQL注入式攻擊襲掠了大量的網站，連蘋果公司的網站也未能幸免。這種猖獗的攻擊向業界招示其日漸流行的趨勢，黑客們也越來越喜歡這種可以滲透進入企業的基礎架構和數據庫資源的攻擊方式。
關于對付SQL注入攻擊的方法已經有許多討論，但是為什么還是有大量的網站不斷地遭受其魔掌呢？安全研究人員認為，現在正是重新梳理最佳方法來對付大規模的SQL注入攻擊的時候，從而減輕與注入攻擊相關的風險。筆者在此介紹的這些方法未必是革命性的創舉，但是又有多少企業真正按照要求全面地實施這些方法呢？
下面，我們將一一談論這些方法：
使用參數化查詢
企業應當制定并強化自行開發軟件的安全編碼指南，要求開發人員使用參數化查詢來構建SQL查詢，這樣就可以將數據與代碼區分開來。
對于多數SQL查詢來說，開發人員需要指明某類標準，為此，就需要利用參數化查詢，其實就是在運行時可傳遞的參數。參數化查詢就是在SQL語句中有一個或多個嵌入參數的查詢。這種將參數嵌入到SQL語句中的方法與動態構造SQL字符串相比，不易產生錯誤。下面我們看一個在.NET應用程序中使用參數化查詢的例子。假設我們想給張三增加工資500元，可參考如下的代碼。這些代碼范例演示了參數化查詢的使用，并展示了如何使用更新語句：
<% @ Page Language="C#" Debug="true"%> <% @Import Namespace="EnterpriseDB.EDBClient" %> <% @Import Namespace="System.Data" %> |
通過利用SQL的更新命令，你可以更新記錄。在上面的例子中，我們作了如下操作：創建并打開一個數據庫鏈接；創建一個代表執行更新語句的數據庫命令；使用EDBCommand 的ExecuteNonQuery()方法執行插入命令。
每一個參數都用一個EDBParameter對象指明。對于需要在SQL語句中指定的每一個參數來說，你需要創建一個EDBParameter對象，然后將值指派給這個對象。然后，將EDBParameter對象添加到EDBCommand命令的參數集中。
對于多數開發平臺來說，應當使用參數化的語句而不是將用戶輸入嵌入到語句中。在許多情況下，SQL語句是固定的，每一個參數都是一個標量，而不是一個表。用戶輸入會被指派給一個參數。下面再給出一個使用Java和JDBC API的例子：
PreparedStatement prep = conn.prepareStatement("SELECT * FROM USERS WHERE USERNAME=? AND PASSWORD=?"); prep.setString(1, username); prep.setString(2, password); prep.executeQuery(); |
筆者用這些例子只是想告訴開發人員，應當確保在查詢數據庫之前對輸入進行凈化。要保障用戶輸入到網站的內容就是你正要查找的數據類型，所以說，如果你正在尋找一個數字，就要努力保障這種輸入一定是一個數字而非字符。
實施過濾和監視工具
在Web應用程序和數據庫這個水平上的過濾和監視工具可有助于阻止攻擊并檢測攻擊行為，從而減輕暴露在大規模的SQL注入式攻擊中的風險。
在應用程序水平上，企業應當通過實施運行時的安全監視來防御SQL注入攻擊和生產系統中的漏洞。同樣地，Web應用防火墻也有助于企業部署某些基于行為的規則集，可以在發生損害之前阻止攻擊。
在數據庫水平上，數據庫活動監視還可以從后臺過濾攻擊。數據庫的監視活動是對付SQL注入的一種很強大的工具。對于目前所知道的注入攻擊而言，應當部署好過濾器，以便向數據庫管理員發出警告：正在發生不太安全的問題；還要有一些一般的過濾器，用以查找SQL注入攻擊中的典型伎倆，如破壞SQL代碼的不規則的數字引用等。
精心編制錯誤消息
黑客可以利用你的錯誤消息，以便于將來對付你。所以開發團隊和數據庫管理員都需要考慮：在用戶輸入某些出乎意料的“數據”時，應當返回的錯誤消息。
企業應當配置Web服務器和數據庫服務器，使其不輸出錯誤或警告消息。因為攻擊者可以利用“盲目SQL注入”等技術來了解你的數據庫設計細節。
及時打補丁并強化數據
由于沒有打補丁或者配置錯誤，而造成與Web應用程序相關聯的數據庫遭受攻擊，那么與SQL注入攻擊相關的風險也會因之增加。
很顯然，只要有補丁可用，你就需要給數據庫打補丁，并且還要給Web應用程序和Web服務打補丁。
此外，別忘了你的數據庫是怎樣配置的。你需要禁用不必要的服務和功能，目的是為了強化數據庫及其賴以運行的操作系統。
限制數據庫的特權
最后，企業需要更好地管理與Web應用程序相關的賬戶與后臺數據庫交互的方式。許多問題之所以發生，其原因在于數據庫管理員全面開放了一些賬戶，其目的是為了讓開發人員更輕松地工作。但是，這些超級用戶賬戶極易遭受攻擊，并會極大地增加由SQL注入攻擊及其它Web攻擊給數據庫所造成的風險。
一定要正確地管理所有的賬戶，使其僅能以最低的特權訪問后臺的數據庫，當然前提是能夠完成其工作。你一定要保障這些賬戶不會擁有對數據庫作出更改的權利。
【編輯推薦】
