譯者 | 李睿

審校 | 重樓

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

什么是SQL注入？

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

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

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

什么是ORM注入?

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

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

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

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

ORM注入

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

"password LIKE '%a%'"

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

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

以下是SQL注入如何被利用的簡(jiǎn)短列表：

• 遠(yuǎn)程代碼執(zhí)行(通常通過(guò)特殊功能)
• 讀寫(xiě)主機(jī)上的文件。
• 顛覆Web應(yīng)用程序的邏輯
• 提取敏感數(shù)據(jù)
• 操縱數(shù)據(jù)
• 拒絕服務(wù)

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

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

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

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

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

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

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

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

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

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

減輕SQLi時(shí)的常見(jiàn)錯(cuò)誤

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

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

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

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

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

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

SQLMap篡改腳本，使用雙美元符號(hào)代替單引號(hào)

最后但并非最不常見(jiàn)的錯(cuò)誤是對(duì)數(shù)據(jù)庫(kù)關(guān)鍵字進(jìn)行非遞歸刪除。這也很容易繞過(guò)檢測(cè)，因?yàn)楣粽呖梢栽谙嗤年P(guān)鍵字中間插入關(guān)鍵字。因此，經(jīng)過(guò)清理之后，注入仍然存在。例如：

“SELSELECTECT” -> “SELECT”

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

防止SQL注入的正確方法

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

使用TypeORM編寫(xiě)語(yǔ)句

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

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

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

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