緩解SQL注入威脅的三種方法

即使是大型科技公司，依然會被軟件和Web漏洞所困擾，其中SQL 注入是常見也是最危險的漏洞之一。在MITRE近日發布的過去兩年中最常見和最危險的25個軟件漏洞列表（見下圖）中，SQL注入漏洞的排名高居第六：

以下是降低SQL注入漏洞風險的三大方法：

零信任方法

首先確保客戶端輸入驗證不是唯一的防線。這種驗證是改善用戶體驗的好工具，但它不能作為一種安全機制。因為，通過更改瀏覽器中加載的JavaScript代碼，或使用導致SQL注入的參數對客戶端-服務器架構中的后端進行基本HTTP調用，可以輕松刪除客戶端驗證。

所以開發人員應該在服務器端進行驗證，且盡可能靠近源；開發人員還應該仔細考慮數據庫用戶權限，所有SQL注入攻擊都是有害的，但有些攻擊比其他攻擊更危險：訪問用戶信息是一回事，更改或刪除信息是另一回事，應考慮特定應用程序是否真的有必要能夠截斷或刪除數據。

除了不允許每個應用程序自由支配一個數據庫之外，一個應用程序只有一個數據庫用戶也是不明智的。應創建多個數據庫用戶，并將其連接到特定的應用程序中進行角色分工，這可以防止攻擊者快速接管整個數據庫。

參數是最好的防御手段

提升軟件安全性的一個關鍵方法是使用預設語句和查詢參數化。預設語句能夠限制可輸入的SQL語句：開發人員創建一個帶有占位符的基本查詢，然后用戶給定的參數可以安全地附加到這些占位符上。在使用預設語句和參數化查詢時，數據庫會首先根據帶有占位符的查詢字符串構建查詢執行計劃，然后將（不可信的）參數發送到數據庫。

使用存儲過程時，參數化也很重要。就像在應用程序中創建的任何SQL查詢一樣，存儲過程也可能被惡意注入。因此，與SQL查詢一樣，開發人員應該在他們的存儲過程中參數化查詢，而不是連接參數，以防止注入。

但是，在某些情況下，預設語句不可用。比如如果某種語言不支持預設語句，或者較舊的數據庫不允許開發人員將用戶輸入作為參數提供，此時輸入驗證是一個可接受的替代方案。但團隊應該確保，輸入驗證依賴的是一個使用維護良好的庫或創建一個規則來描述所有允許的模式，例如，使用正則表達式。當然，即使預設語句可用，輸入驗證也是必須的。

多層安全和嚴格檢查

除了參數化和輸入驗證之外，開發人員還應考慮使用對象關系映射 ( ORM ) 層來防止SQL注入。將數據從數據庫轉換為對象，反之亦然，從而減少了顯式SQL查詢和SQL注入攻擊的風險。但是需要注意的是，如果使用錯誤、過時的Sequelize或Hibernate版本，ORM庫中仍然會產生漏洞，因此開發人員必須保持警惕。

最終，無論部署什么安全策略，都必須有一個嚴格的審查系統來審查代碼并標記所有漏洞。代碼審查和結對編程確實允許這樣做，但手動審查過程總是存在誤差。為了獲得最高級別的安全性，開發人員應該尋找專門設計的掃描工具來自動檢查SQL注入漏洞并提醒他們代碼中的所有弱點。