加強(qiáng)Web應(yīng)用程序安全：防止SQL注入

　　譯者 | 李睿

　　數(shù)據(jù)庫在Web應(yīng)用程序中存儲和組織數(shù)據(jù)時(shí)起著至關(guān)重要的作用，它是存儲用戶信息、內(nèi)容和其他應(yīng)用程序數(shù)據(jù)的中央存儲庫。而數(shù)據(jù)庫實(shí)現(xiàn)了高效的數(shù)據(jù)檢索、操作和管理，使Web應(yīng)用程序能夠向用戶提供動態(tài)和個性化的內(nèi)容。然而，數(shù)據(jù)庫和網(wǎng)絡(luò)應(yīng)用程序之間的通信不暢可能會導(dǎo)致敏感數(shù)據(jù)泄露、用戶不信任、法律后果和利潤損失。本文將探討導(dǎo)致此類災(zāi)難的后端錯誤配置，并了解如何確保應(yīng)用程序的安全。

　　什么是SQL注入?

　　SQL注入(SQLi)是一個漏洞，它允許網(wǎng)絡(luò)攻擊者篡改Web應(yīng)用程序發(fā)送給數(shù)據(jù)庫的查詢。當(dāng)應(yīng)用程序誤解了用戶的輸入并將其視為SQL代碼而不是字符串時(shí)，就會發(fā)生注入。因此，惡意用戶可以更改預(yù)期的查詢流，破壞應(yīng)用程序的邏輯，并獲得對其資源的未經(jīng)授權(quán)的訪問。

　　在大多數(shù)情況下，當(dāng)開發(fā)人員需要使用依賴于用戶輸入的參數(shù)化查詢時(shí)，就會出現(xiàn)SQLi。如果開發(fā)人員在將用戶輸入插入模板之前忘記對其進(jìn)行適當(dāng)?shù)那謇恚�就會引入SQL注入漏洞。一個經(jīng)典的SQL注入示例是使用純字符串插值或連接來創(chuàng)建動態(tài)查詢，如下圖所示。網(wǎng)絡(luò)攻擊者可以通過用SQL代碼替換分頁參數(shù)中的數(shù)字來注入任意SQL語句。

　　動態(tài)查詢精心制作的字符串插值

　　什么是ORM注入?

　　現(xiàn)在，開發(fā)人員很少使用原始SQL語句，而是使用稱為ORM的特殊框架。對象關(guān)系映射(ORM)是一種用作兩種不同范例之間的適配器的技術(shù)：關(guān)系(將數(shù)據(jù)存儲在表中)和面向?qū)ο?將數(shù)據(jù)存儲在對象中)。ORM所做的事情之一是在底層生成SQL代碼。開發(fā)人員所要做的就是告訴ORM如何去做。

　　顯然，自動生成意味著自動轉(zhuǎn)義用戶提供的數(shù)據(jù)。ORM確保每個動態(tài)參數(shù)都像普通字符串一樣被處理，除非開發(fā)人員特別禁用清理功能。然而，惡意代碼的注入仍然是可能的。ORM注入是一個漏洞，它允許密切協(xié)作攻擊者強(qiáng)制ORM生成對他們有利的SQL。

　　考慮下面的例子。這里有一個函數(shù)，它應(yīng)該接受帶有多個參數(shù)的對象過濾器，例如:

　　復(fù)制

　　{"email":, ""name": "user"}

　　ORM注入

　　但是，開發(fā)人員忘記檢查過濾器是否確實(shí)是一個對象，以及它是否只包含安全的過濾參數(shù)。這樣的錯誤使攻擊者能夠注入可用于恢復(fù)用戶密碼的惡意過濾器，例如：

　　"password LIKE '%a%'"

　　SQL注入真的很危險(xiǎn)嗎?

　　通常，SQL注入可以被認(rèn)為是一個嚴(yán)重的漏洞。在大多數(shù)情況下，對網(wǎng)站任何部分的單個SQL注入最終都可以擴(kuò)展到在數(shù)據(jù)庫上運(yùn)行任何查詢，提取和操作其數(shù)據(jù)。由于數(shù)據(jù)庫通常保存著系統(tǒng)中最敏感的信息，因此允許網(wǎng)絡(luò)攻擊者訪問這些信息是毀滅性的。

　　以下是SQL注入如何被利用的簡短列表：

　　遠(yuǎn)程代碼執(zhí)行(通常通過特殊功能)

　　讀寫主機(jī)上的文件。

　　顛覆Web應(yīng)用程序的邏輯

　　提取敏感數(shù)據(jù)

　　操縱數(shù)據(jù)

　　拒絕服務(wù)

　　哪些類型的SQL注入是可能的?

　　在通常情況下，有三種類型的SQL注入：帶內(nèi)注入、帶外注入和盲注入。反過來，帶內(nèi)攻擊可以是基于聯(lián)合的或基于錯誤的，而盲SQLi可以是基于布爾的或基于時(shí)間的。

　　SQL注入層次結(jié)構(gòu)

　　如果攻擊者足夠幸運(yùn)，他們可以在后端響應(yīng)中包含被破壞的SQL查詢的結(jié)果。這被稱為帶內(nèi)SQLi。帶內(nèi)SQLi有兩種子類型：

　　1.基于聯(lián)合的SQLi：攻擊者能夠指定他們可以讀取的查詢輸出的位置(列)。

　　2.基于錯誤的SQLi：當(dāng)應(yīng)用程序公開SQL/編程語言錯誤時(shí)，這種類型的SQLi是可能的。在這種情況下，攻擊者可以分析錯誤消息/堆棧跟蹤，并推斷攻擊是否成功。

　　使用BlindSQLi，網(wǎng)絡(luò)攻擊者無法看到被破壞的SQL查詢的結(jié)果。然而，它們有某種反饋，可以幫助確定是否存在注入。盲SQLi有兩種子類型：

　　1.基于布爾的SQL：攻擊者可以使用SQL條件語句以某種方式修改服務(wù)器的響應(yīng)。然后，他們可以將這種新的反應(yīng)與原來的反應(yīng)進(jìn)行比較，并確定注入是否有效。

　　2.基于時(shí)間的SQLi：攻擊者可以將數(shù)據(jù)庫的SLEEP函數(shù)與條件語句結(jié)合起來，從而延遲后端響應(yīng)。然后，他們可以將原始響應(yīng)時(shí)間與新的響應(yīng)時(shí)間進(jìn)行比較，以確定注入是否成功。

　　在某些情況下，攻擊者可能根本無法從數(shù)據(jù)庫獲得任何反饋。在這種情況下，它們可以強(qiáng)制數(shù)據(jù)庫將輸出重定向到另一個位置，并嘗試從那里讀取它。這就是所謂的帶外SQL注入。例如，他們可以強(qiáng)制數(shù)據(jù)庫將包含敏感信息的DNS查詢發(fā)送到他們控制的DNS服務(wù)器�；蛘撸�它們可以強(qiáng)制數(shù)據(jù)庫將一些數(shù)據(jù)寫入可公開訪問的文件中。這種注入會影響許多數(shù)據(jù)庫。

　　減輕SQLi時(shí)的常見錯誤

　　用戶不應(yīng)該試圖為SQL輸入?yún)��?shù)提供自己的清理程序。這樣做需要深入了解數(shù)據(jù)庫規(guī)范和使用它們的經(jīng)驗(yàn)。最有可能的是，最終會淹沒在其他人無法理解的正則表達(dá)式中，并且隨著數(shù)據(jù)庫的發(fā)展，沒有人會支持清理程序。

　　需要記�。汗�擊者總是試圖混淆他們的SQLi有效負(fù)載，將其偷運(yùn)到WAF和IPS。有大量的框架可以利用SQLi，為攻擊者提供扭曲有效負(fù)載的腳本庫。編寫自定義混淆處理程序并將其與現(xiàn)有混淆處理程序結(jié)合使用也很容易。

　　考慮一下開發(fā)人員在試圖凈化用戶輸入時(shí)所犯的一些常見錯誤。

　　一個常見的誤解是，可以通過刪除/替換SQL查詢參數(shù)中的空格來避免SQLi。例如，如果攻擊者只能使用一個單詞，會造成多大的傷害?但是許多數(shù)據(jù)庫將注釋轉(zhuǎn)換為空格，因此“SELECT email FROM user”等于“SELECT/**/email/**/FROM/**/user”，這是一個單詞。

　　使用注釋而不是空格的SQLMap篡改腳本

　　通常認(rèn)為刪除引號可以使參數(shù)安全，但有時(shí)攻擊者可以指定另一個特殊字符來定義字符串。例如，PostgreSQL允許定義包含在雙美元符號中的多行字符串。所以“email”等于$$ email$$。

　　SQLMap篡改腳本，使用雙美元符號代替單引號

　　最后但并非最不常見的錯誤是對數(shù)據(jù)庫關(guān)鍵字進(jìn)行非遞歸刪除。這也很容易繞過檢測，因?yàn)楣�擊者可以在相同的關(guān)鍵字中間插入關(guān)鍵字。因此，經(jīng)過清理之后，注入仍然存在。例如：

　　“SELSELECTECT” -> “SELECT”

　　用于嵌套關(guān)鍵字的SQLMap篡改腳本

　　防止SQL注入的正確方法

　　防止SQLi的第一步是使用預(yù)處理語句。允許用戶定義預(yù)處理語句也是不可接受的。這里有一個使用TypeORM防止SQL注入的例子：采用硬編碼的模板，并使用這個框架的特性來安全地插入變量：

　　使用TypeORM編寫語句

　　但是僅僅使用ORM是不夠的。正如前面看到的，業(yè)務(wù)邏輯缺陷可以允許繞過安全保護(hù)措施。SQLi修正的第二步是顯式驗(yàn)證用戶輸入。如果需要一個數(shù)字，可以手動將值轉(zhuǎn)換為數(shù)字。如果需要URL，可以手動將輸入字符串轉(zhuǎn)換為URL。這種方法顯著降低了利用SQLi的可能性。額外的好處是，將擁有更一致的數(shù)據(jù)和更少的錯誤。有許多庫可用于聲明性驗(yàn)證，例如express-validator或class-validator。

　　另一件需要記住的重要事情是始終為每個應(yīng)用程序創(chuàng)建一個專用的數(shù)據(jù)庫用戶。仔細(xì)閱讀有關(guān)默認(rèn)用戶權(quán)限的文檔，并禁用除了對應(yīng)用程序運(yùn)行至關(guān)重要的功能之外的所有功能。除了數(shù)據(jù)庫管理之外，永遠(yuǎn)不應(yīng)該將DBA帳戶用于其他任何事情。默認(rèn)情況下，DBA帳戶被授予所有可能的權(quán)限。這顯著地放大了SQL注入的嚴(yán)重性。

　　最后但同樣重要的是，使用Web應(yīng)用程序防火墻或入侵預(yù)防系統(tǒng)。它們能夠發(fā)現(xiàn)并破壞SQL注入攻擊，甚至有一組流量規(guī)則來檢測依賴SQLi的已知漏洞。當(dāng)然，使用WAF或IPS并不是靈丹妙藥，因?yàn)樗鼈兛梢岳@過檢測。然而，這種工具的存在顯著提高了進(jìn)行攻擊所需的知識閾值。另外，WAF/IPS干擾了SQLi開發(fā)自動化，并提供了比傳統(tǒng)工具更好的日志記錄。

　　原文標(biāo)題：Strengthening Your Web App Security: Preventing SQL Injections，作者：Conty Write