SQL注入有病 安全專家有良方

■丁燕

SQL注入有病 安全專家有良方

■丁燕

SQL注入攻擊現狀

SQL注入攻擊是一個非常老的攻擊方式，由于很多應用程序都存在SQL注入漏洞而且SQL注入方式與手段變化多端，盡管大型企業一般都花巨資購買多種安全保護系統，但是SQL注入攻擊導致企業蒙受損失的新聞還是層出不窮：

香港航空某站SQL注入（涉及156萬乘客信息/268萬機票信息/八千多員工信息）；中石化車e族APP存在SQL注入漏洞之一（可跨9個庫）；海爾旗下日日順商城SQL注入導致300萬會員信息泄漏；邯鄲市工信辦漏洞危及大量個人信息以及金額等數據，百萬用戶數據泄露；中國電信翼支付某系統漏洞泄露400萬用戶信息、支付交易明細信息（超市購物/加油站加油）以及充值等數據。

從這些例子可以看出SQL注入是當前應用安全防護的重點和難點，是什么原因導致如此古老的攻擊方式在當今安全軟件如此豐富的情況下依舊導致這么大傷害呢？筆者認為有以下幾點：

SQL注入漏洞大面積的存在：當今系統越來越復雜，發布節奏越來越快，遺漏代碼非常多。很多公司對安全不夠重視，帶病上線是非常常見的事情。

關系型數據庫是現在最流行的存儲方式，大多數有價值的信息都存在數據庫里。這對黑客的誘惑力太大了。

攻擊方式并不難找，網絡有大量的SQL注入攻擊的方法和手段。黑客很容易找到攻擊的方式。

SQL注入的原理

SQL注入：就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串里，最終達到欺騙服務器執行惡意的SQL命令。

具體來說，它是利用現有應用程序，將（惡意）的SQL命令注入到后臺數據庫引擎執行的能力，它可以通過在Web表單輸入（惡意）SQL語句得到一個存在安全漏洞的網站的數據庫信息，而不按照設計者的意圖執行SQL語句。

首先讓我們了解下什么時候可能發生SQL注入：

假設我們在瀏覽器中輸入URL:www.sample.com，由于它只是對頁面的簡單請求無需對數據庫進行動態請求，所以它不存在SQL注入，當輸入www.sample.com testid=23時，我們在URL中傳遞了變量testid，并且提供值為23，由于它是對數據庫進行動態查詢的請求（其中testid=23表示數據庫查詢變量），所以我們可以在該URL中嵌入了惡意SQL語句。

具體的例子和詳細的原理就不贅述了，有興趣的同學可以去谷歌或者百度搜索，上面會有大量的例子和攻擊方式。

SQL注入常用保護方式

最主要的保護方式有以下幾點：

使用Prepared Statements（參數查詢）來代替Statements—這要求所有數據庫開發人員在開發SQL查詢語句時將代碼和數據分開，先定義查詢語句的結構，將數據通過參數的方式出入，這樣輸入的參數將不會當作SQL命令來執行，基本上能避免SQL注入的攻擊。

使用存儲過程來操作數據庫——所有的存儲過程都存放在數據庫里面，應用程序調用存儲過程來查詢數據。

轉義用戶輸入的所有特殊字符——永遠不要信任用戶的輸入，要對用戶的輸入進行校驗，可以通過正則表達式，或限制長度，對單引號和雙"-"進行轉換等。這些在一定程度可以緩解SQL注入。

還有些輔助的方法：

以最低權限的數據庫連接，為每個應用使用單獨的權限與有限的數據庫連接。不要把機密信息明文存放，加密或者hash掉密碼和敏感的信息。應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝，把異常信息存放在獨立的表中。RASP從根本上解決SQL注入攻擊。

上面描述的是一些非常有用的SQL防護手段，但是都存在需要花費大量的精力制定代碼規范的缺點，確保每個程序員都能按照這個規范來編寫代碼。但是現在的程序都非常復雜，代碼量動輒百萬行，需要非常多的程序員一起完成，要確保每個程序員寫出完全符合安全規范的代碼是完全不可能的。有些公司通過第三方代碼掃描工具對代碼進行靜態和動態掃描，試圖發現和修復所有SQL注入的漏洞，在實踐中也非常不理想，以下幾個方面的約束使這種想法很難實現：

代碼量巨大，完全修復這些漏洞要花費巨大的人力和時間，在大多數公司基本不可能實現。掃描工具漏洞更新比較滯后，很多漏洞都不能得到及時更新。即使完全修復，上線后也會有新的漏洞產生。一般項目都會大量使用第三方API和框架，這些外部程序的漏洞是不可修改的，即使提供商承諾修改也需要比較長得時間。

現在有很多的安全產品，包括傳統防火墻，WAF（Web防火墻）等等，這些安全產品基本上是根據數據流掃描的結果來提供保護，并不了解應用程序的上下文，所以不能精確識別攻擊行為，更談不上有效的保護，再加之現在云計算越來越盛行，傳統的有清晰邊界的網絡拓撲結構也越來越少，因此這些產品對類似于SQL注入等應用安全攻擊效果并不好。

那么安全專家有什么好的建議呢？他們推薦了RASP，這是最近非常流行的應用安全保護方案，它是在應用程序運行時進行自我保護，它將實時代碼漏洞掃描和Web防火墻實時攔截安全攻擊的能力組合起來，像疫苗一樣將安全保護代碼注入到應用程序中。它無需修改任何代碼，簡單修改JVM啟動腳本就可以和應用程序結合在一起，在應用程序運行時一起運行，擁有應用程序的上下文，可以根據具體的用戶行為有針對性行的進行安全監控和保護，既可以精確的識別和防范安全攻擊，也可以最大限度的降低對性能和用戶體驗的影響。

而具體到SQL注入保護方面，RASP做得非常完美。它就像一個大的虛擬補丁，將大部分已知的SQL注入漏洞進行修補，確保大部分漏洞得到保護。這樣大部分的攻擊將無效，目前國內已知的僅有OneRASP具備這樣的防護能力。

對于未知漏洞OneRASP將建立實時漏洞更新系統，能及時更新最新漏洞，在不影響用戶系統的前提下，確保用戶及時有效地抵御零日攻擊。

對于無法預知的SQL注入方式，OneRASP也有辦法防御。常見的SQL注入保護方式往往采用通用的方法，而每個數據庫的實現方式有很大的不同，這些通用的方式必然會有遺漏之處。對安全來說任何遺漏都是致命的，黑客可以利用任何可乘之機獲得機密。OneRASP對SQL注入保護非常完整，它將保護代碼植入SQL注入攻擊的必經點：JDBC的各個廠家的實現類Statement.class里面，每個保護動作都是在對數據庫SQL語言的實現完全理解的基礎上編寫的，考慮SQL注入的每種攻擊可能，實現從根上對SQL注入的完整保護。