譯者 | 李睿

審校 | 重樓

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

什么是SQL注入？

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

在大多數情況下，當開發人員需要使用依賴于用戶輸入的參數化查詢時，就會出現SQLi。如果開發人員在將用戶輸入插入模板之前忘記對其進行適當的清理，就會引入SQL注入漏洞。一個經典的SQL注入示例是使用純字符串插值或連接來創建動態查詢，如下圖所示。網絡攻擊者可以通過用SQL代碼替換分頁參數中的數字來注入任意SQL語句。

動態查詢精心制作的字符串插值

什么是ORM注入?

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

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

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

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

ORM注入

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

"password LIKE '%a%'"

SQL注入真的很危險嗎?

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

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

• 遠程代碼執行(通常通過特殊功能)
• 讀寫主機上的文件。
• 顛覆Web應用程序的邏輯
• 提取敏感數據
• 操縱數據
• 拒絕服務

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

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

SQL注入層次結構

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

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

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

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

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

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

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

減輕SQLi時的常見錯誤

用戶不應該試圖為SQL輸入參數提供自己的清理程序。這樣做需要深入了解數據庫規范和使用它們的經驗。最有可能的是，最終會淹沒在其他人無法理解的正則表達式中，并且隨著數據庫的發展，沒有人會支持清理程序。

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

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

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

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

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

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

最后但并非最不常見的錯誤是對數據庫關鍵字進行非遞歸刪除。這也很容易繞過檢測，因為攻擊者可以在相同的關鍵字中間插入關鍵字。因此，經過清理之后，注入仍然存在。例如：

“SELSELECTECT” -> “SELECT”

用于嵌套關鍵字的SQLMap篡改腳本

防止SQL注入的正確方法

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

使用TypeORM編寫語句

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

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

最后但同樣重要的是，使用Web應用程序防火墻或入侵預防系統。它們能夠發現并破壞SQL注入攻擊，甚至有一組流量規則來檢測依賴SQLi的已知漏洞。當然，使用WAF或IPS并不是靈丹妙藥，因為它們可以繞過檢測。然而，這種工具的存在顯著提高了進行攻擊所需的知識閾值。另外，WAF/IPS干擾了SQLi開發自動化，并提供了比傳統工具更好的日志記錄。

原文標題：Strengthening Your Web App Security: Preventing SQL Injections，作者：Conty Write