SQL注入防御技術研究與實現

吳宗卓

（陜西國防工業職業技術學院，陜西西安，710300）

SQL注入防御技術研究與實現

吳宗卓

（陜西國防工業職業技術學院，陜西西安，710300）

全世界每年由于 SQL 注入攻擊而造成的經濟損失慘不忍睹。本文從SQL注入簡介入手從程序設計和實現以及平臺上的防御兩個方面探究了SQL注入的防御技術。

SQL注入；防御技術；平臺防御

1 SQL注入簡介

SQL注入攻擊是黑客對數據庫進行攻擊的常用手段之一。隨著 B/S 模式應用開發的發展，使用這種模式編寫應用程序的程序員也越來越多。但是由于程序員的水平及經驗參差不齊，相當大一部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段數據庫查詢代碼，根據程序返回的結果，獲得某些他想得知的數據，這就是所謂的 SQLInjection，即 SQL注入。

2 SQL注入程序的設計和實現上的防御

本例將創建存儲過程以執行應用需要的所有數據庫訪問。為應用訪問數據庫所使用的數據庫用戶分配執行應用所需要的存儲過程的許可，但不要為它分配數據庫中其他的數據許可(例如，用戶賬戶沒有對應用數據執行 SELECT、INSERT 或UPDATE 操作的權利，但是擁有存儲過程的EXECUTE 權利)，接下來存儲過程使用不同的許可訪問數據(例如創建存儲過程而非調用存儲過程的用戶許可)并按需與應用數據進行交互。這樣有助于減輕 SQL注入問題的影響，因為它會限制攻擊者只能調用存儲過程，從而限制了攻擊者能夠訪問或修改的數據。在很多情況下，這么做可以防止攻擊者訪問數據庫中的敏感信息。

使用抽象層設計商業應用時，常見的做法是為表示、業務邏輯和數據訪問定義不同的層，從而將每一 層的實現從總體設計中抽象出來。根據使用技術的不同，這種做法可能涉及Hibernate 這樣的附加數據訪問抽象層以及使用 ADO.NET、JDBC 或 PDO 這樣的數據庫訪問框架。這些抽象層非常有助于那些意識到安全性的設計者們加強數據的安全訪問行為。這些行為之后會被用在架構的其他位置。

確保使用參數化語句來執行所有數據庫調用的數據訪問層是這種抽象層的一個很好的例子。假設應用除了以數據訪問層方式訪問數據庫之外，不存在其他訪問方式，而且之后沒有使用數據庫層的動態 SQL提供的信息，那么基本不可能出現 SQL注入。更強有力的做法是將這種訪問數據庫的方法與使用存儲過程結合起來，這樣可以進一步減輕 SQL注入的風險。這種方法還具有簡化實現的效果，因為它已經定義了訪問數據庫的所有方法， 所以在設計良好的數據訪問層中更容易實現。

處理敏感數據最后一種減輕 SQL注入嚴重影響的技術是考慮數據庫中敏感信息的存儲和訪問。攻擊者的目標之一是獲取對數據庫所存儲數據的訪問權，這些數據通常包含某種形式的貨幣值。攻擊者有興趣獲取的信息包括用戶名和口令、個人信息或信用卡明細這樣的財務信息。因此，我們有必要對敏感信息進行附加的控制。下面給出一些控制示例或者需要考慮的設計決策：

口令如果可能的話，不應該在數據庫中存儲用戶口令。比較安全的做法是存儲每個用戶口令的 salted 單向哈希而不是口令本身。接下來比較理想的做法是將 salt 與哈希口令分開保存。對于這種情況，登錄時不要比較用戶口令和數據庫中保存的口令，而應將通過用戶提供的信息計算出來的 salted 哈希與數據庫中保存的哈希值進行比較。

信用卡及其他財務信息應該使用認可的加密算法來對信用卡等信息進行加密，然后存儲加密后的明細數據。這是 PCI-DSS對信用卡信息作出的一個要求。不過還應該考慮對應用中的其他財務信息進行加密。

存檔如果未要求應用保存提交給它的所有敏感信息的完整歷史記錄，則應考慮每隔一段合理的時間就存檔或淸除這些不需要的信息。如果初始處理后應用不再需要這些信息，則應該立即存檔或清除它們。對于這種情況，清除信息可以降低未來安全破壞帶來的影響，它通過減少攻擊者能夠訪問的顧客信息量來實現該目的。避免明顯的對象名出于安全方面的原因，在為關鍵對象選取名稱時應該格外小心。

白名單

名單驗證是只接收己記錄在案的較好輸入的操作。它在接收輸入并做進一步處理之前驗證輸入是否符合所期望的類型、長度或大小、數字范圍或者其他格式標準。例如，要驗證輸入值是個信用卡編號，則可能包括驗證輸入值只包含數字、總長度在13和16之間并且準確通過了Luhn公式的業務邏輯校驗。

黑名單

黑名單驗證是只拒絕己記錄在案的不良輸入的操作，它通過瀏覽輸入的內容來查找是否存在己知的不良字符、字符串或模式。如果輸入中包含這些眾所周知的惡意內容，黑名單驗證通常會拒絕它。一般來說，這種方法的功能比白名單驗證要弱一些，因為潛在的不良字符列表非常大，這可能會導致不良內容列表很大，檢索起來比較慢且不完全，而且很難及時更新這些列表。

3 SQL注入平臺上的防御

在代碼層防止sQL注入時可以采取的操作和防御措施。本章將注意力轉移到檢測、減輕并阻止sQL注入的平臺層防御。平臺層防御是指能提高應用總體安全的運行時優化處理或配置更改。本章涉及的保護范圍會有所變化，不過從整體來看，我們介紹的技術將有助于實現一種多層的安全架構。

我們將首先介紹運行時保護技術和技巧，比如Web服務器插件和影響應用框架的特性。接下來介紹確保數據庫中數據及數據庫自身的安全策略，以減少可利用的SQL注入漏洞帶來的影響。最后看一下在基礎結構層可以進行哪些措施以降低威肋。

最小化不必要信息的泄露一般來說，泄露與軟件行為有關的不必要信息明顯會幫助攻擊者發現應用中的弱點。這些信息包括軟件版本信息(可用于跟蹤潛在的易受攻擊應用的版本)和與應用失敗有關的錯誤明細，比如發生在數據庫服務器上的SQL語法錯誤。我們將介紹一些在應用部署描述符文件中顯式隱藏這些信息并強化Web服務器配置的方法。

使用應用層錯誤處理程序處理異常和錯誤消息隱藏會極其有效。不過，運行時不可避免地會存在出現未預料條件的可能性。所以，好的做法是配置應用框架和(或)Web服務器以便在產生未預料的應用錯誤時返回一個自定義響應。配置后的響應可以是個顯示通用消息的自定義錯誤頁面，也可以重定向到默認的Web頁面。關鍵是該頁面+應該顯示與異常產生原因相關的任何技術細節。例如可以這樣對應用和Web服務器進行配置以便產生錯誤條件時返回自定義響應。

一種可以使基于響應的錯誤檢測變得困難的方法是配置應用和Web服務器使之返回相同的響應，比如不管什么錯誤代碼(401, 403, 500等)均重定向到默認的主頁。很明顯，采用這種策略時應該倍加小心，因為它同樣會使合法的應用調試行為變得困難。如果設計應用時包含了良好的錯誤處理和日志記錄，而它們能夠為應用管理員提供足夠的細節來重構該問題，那么此時值得考慮采用該策略。

使用空的默認Web站點HTTP/1.1協議要求HTTP客戶端在發送給Web服務器的請求中發送主機頭部。

為訪問特定的Web站點，該頭部值必須與Web服務器的虛擬主機配置中的主機名相匹配。如果未找到匹配值，將返回歇認的Web站點內容。例如，嘗試通過IP地址連接到Web站點時，會返回默認的Web站點內容。例如這樣:

企業級Web應用的擁有者則可能喜歡更隱蔽些，他們不希望被針對端口80和443進行IP地址范圍掃描的攻擊者發現。為確保用戶，需要將Web服務器的默認Web站點配置成返回空的默認Web頁面。假設合法用戶喜歡易記的主機名，那么通過IP地址進行的訪問嘗試將會是一種很好的檢測潛在入侵嘗試的方法。最后，值得指出的是，這是一種深度防御機制，它雖然無法完全阻止不想要的發現，但卻可以有效應對通過IP地址查找來識別易受攻擊的Web站點的自動掃描程序。

[1] 那勇. SQL 注入攻擊的分析和防范方法[J]. 吉林廣播電視大學學報. 2010(11)

[2] 王志虎. SQL 注入攻擊及其預防方法研究[J]. 煤炭技術. 2011(01)

Research and implementation of SQL injection Defense Technology

Wu Zongzhuo
(Shaanxi Institute of Technology, Shaanxi Xi'an, 710300)

every year in the world due to the economic losses too horrible to look at SQL injection attacks. This article from the introduction of SQL to start from the program design and implementation and defense on the platform to explore the two aspects of SQL injection defense technology.

SQL injection; defense technology; platform defense