SQL 注入有病，安全專家有何良方？

SQL 注入攻擊現狀

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

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

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

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

2. 關係型資料庫是現在最流行的儲存方式，大多數有價值的資訊都存在資料庫裡。這對黑客的誘惑力太大了。

3. 攻擊方式並不難找，網路有大量的 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隱碼攻擊常用保護方式

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

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

2. 使用儲存過程來運算元據庫 — 所有的儲存過程都存放在資料庫裡面，應用程式呼叫儲存過程來查詢資料。

3. 轉義使用者輸入的所有特殊字元 – 永遠不要信任使用者的輸入，要對使用者的輸入進行校驗，可以通過正規表示式，或限制長度，對單引號和雙"-"進行轉換等。這些在一定程度可以緩解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 注入的完整保護。

OneRASP 是應用效能管理領軍企業 OneAPM 公司最新推出的 RASP（執行時應用程式自我保護系統）應用程式保護方案。這是國內第一款 RASP 安全產品，其穩定性、準確性、易用性以及對應用程式效能和使用影響非常小的這些特點，給很多開發者留下了深刻的印象。但是由於是新推出的產品，還需要時間的檢驗，有興趣的同學可以訪問 OneASP 的官網。