正確的 WAF 配置對網絡安全是如此重要

有研究人員在安全測試時，繞過了 Cloudflare WAF 的 SQLi 過濾器，這意味著Cloudflare 安裝沒有正確配置，但Cloudflare目前還不認為這是個漏洞。雖如此，安全人員在為其應用程序部署安全保護時需要注意有關問題。對于試圖繞過 WAF 的人來說，發現的些許漏洞也可能會派上用場。攻擊者可以利用一種或多種技術（具體取決于最終應用程序）繞過某些 WAF 并通過濫用 SQLi 漏洞竊取數據。

測試時使用的Web應用程序詳細信息

測試時使用的Web 應用程序的目的對于實際測試來說并不重要。除了在服務器上公開的 /graphql 端點和運行查詢的 PostgreSQL 服務之外，寫入查詢的堆棧也并不重要。GraphQL 是一種查詢語言，它處理查詢，在測試中，在后端運行適當的 SQL 查詢并返回請求的數據。之前由于測試人員從未使用或閱讀過有關 GraphQL 的信息，因此遵循的是官方教程https://graphql.org/learn/，如果感興趣你也可以了解一下。

查詢的形成類似于 JSON 對象。應用程序向 /graphql 端點發送 POST 請求。請求正文包含 GraphQL 查詢，如下所示：

X-MARK 中未過濾的參數從 GraphQL 傳遞，并在 PostgreSQL 存儲過程中被替換，從而允許我們注入在后端服務器上執行的 SQL 查詢。

這幾乎是我們目前必須了解的關于應用程序的內容。在接下來的部分中，我將介紹我在測試 SQL 注入應用程序時觀察的一些現象，這些觀察使我成功地利用了SQL注入，包括繞過Cloudflare SQLi過濾器。

觀察 1

第一個重要的觀察結果是服務器對有效的電子郵件輸入（即當 SQL 查詢返回數據時）的響應與對無效的電子郵件輸入的響應不同。返回的 HTTP 代碼始終為 200，但響應正文不同：

這將返回“OK”：

這將返回"NOT OK"：

起初這可能看起來不太像，但它實際上是允許我驗證數據庫中特定數據是否存在的機制。它讓我想到了利用這種機制執行SQL盲注入攻擊并使用腳本自動化它的想法。該腳本構造一個有效負載，并將其與POST請求一起發送，POST請求反過來修改在后端服務器上運行的SQL查詢。

步驟如下：

我們有一組字符，稱為字母表。這組字符包括所有可能的字符，這些字符可以是我們試圖從數據庫中提取的數據的一部分。

假設資源是需要檢索的 SQL 資源。它可以是數據庫名稱、用戶名、任何表格中的單元格值等。

將逐字符檢索資源。我們試圖檢索的字符稱為 char。

我們遍歷字母表，并將每個字母與 char 進行比較。

如果有匹配，我們記錄結果并移動到下一個字符。

最后，我們通過連接所有字符獲得了完整的資源。

觀察 2

第二個重要的觀察結果是，在執行的SQL查詢出現錯誤時，會顯示錯誤消息，這對我來說容易得多。這個錯誤信息不允許我執行一個基于錯誤的SQL注入，而是顯示了由PostgreSQL在SQL服務器上執行的完整SQL查詢。這一點為什么如此重要，我們很快就會明白。

從錯誤消息中提取的SQL查詢看起來像這樣：

作為“email”變量提交的用戶輸入反映在X-MARK上。這就是為什么擁有完整的SQL查詢對于開發過程很重要的兩個原因：

可以看到用戶輸入被括在括號中，這條信息使有效負載的生成過程變得更加容易，因為人們知道輸入必須包含與左括號匹配的右括號，以便結束 SQL 查詢有效。

用戶輸入反映在查詢中的多個位置（第 5、10、11 行），給我帶來麻煩的是第 5 行。如果是 X-MARK 僅反映在 WHERE 子句中的情況，事情會更容易。但在這種情況下，我必須確保我的輸入不會弄亂表 JOIN。這是必要的，以確保生成和查詢正確的表行，以便我可以獲得所需的數據。

注意：第 8 行的 $1 符號是 SQL 準備查詢的位置參數，并由 HTTP 請求的“名稱”變量參數替換。但它不容易受到 SQL 注入的影響。

第一次嘗試

我首先嘗試查找當前數據庫的名稱。在 PostgreSQL 中執行此操作的 SQL 查詢是：

有很多事情需要考慮，而且從一開始就很瘋狂，我必須從一開始就想出繞過 Cloudflare 的方法。

WAF 繞過的第一種辦法

首先，我必須首先將 current_database() 的第一個字符與字符“a”進行比較。PostgreSQL的方法是：

Cloudflare會阻塞'substr'函數，所以訣竅是要么使用'left'，要么使用'right'函數。我使用'right'函數，因為'left'給了我一些麻煩，當我試圖找出我已經找到所有的數據庫名稱的字符。新的查詢（將“a”與最后一個資源的字符進行比較，如下所示：

并且未被 WAF 檢測到。

注意：函數 right(current_database(), N) 返回數據庫名稱最右邊的 N 個字符。因此，當找到最后一個字符時，例如X，下一次調用該函數應該是：

由于我們已經知道我們必須關閉查詢中的左括號（來自觀察2），POST 請求的正文如下所示（此處僅顯示'email'變量）：

但是，記住后端 SQL 查詢如何包含 JOIN 子句（來自觀察2），我還在查詢中添加了一些額外的內容，以確保 SQL 連接在后臺正確執行。POST 請求的正文如下所示：

服務器上的后續 SQL 查詢如下所示：

這很復雜，但想法是一樣的：如果“a”是數據庫名稱的最右邊的字符，我們將從服務器獲得一個“OK”響應。

無論如何，在向服務器提交這個請求后，我看到了Cloudflare WAF(配置錯誤)的可怕頁面，告訴我我的請求被阻止了。

第二次嘗試

在我再次嘗試之前，我必須了解 Cloudflare 對我的查詢有什么幫助。

經過反復測試，我發現問題出在生成的服務器 SQL 查詢中的 FROM 子句中的空格。這導致我進入第二個 WAF 繞過。

WAF 繞過的第二種辦法

此處使用的第二種 WAF 繞過技術消除了 SQL 查詢中的空格，并將 SQL FROM 子句的部分括在括號中。

變成了

因此 POST 請求的結果正文變為：

在服務器上的后續SQL查詢是這樣的：

這樣，整個過程就可以實現自動化了，以找到數據庫名稱的整個值。相同的過程還檢索了用戶名（通過使用 user 函數）和數據庫版本（通過使用 version() 函數）。但是存儲在數據庫表中的數據呢？檢索這些數據的通用查詢，以及我在上一篇文章中使用的繞過方法的查詢都不起作用。兩者都被阻止：

為什么我的查詢被阻止了？問題是緊跟在 SELECT 子句之后的 FROM 子句。以下查詢將很好地通過（錯誤配置的）Cloudflare WAF SQLi 過濾器：

一旦在查詢結束時引入 WHERE 子句，WAF 就會啟動并阻止請求。我的最終目標是從任何表中檢索數據。是時候深入挖掘兔子洞了。

第三次嘗試

我在這里給出 SQLi 的早期失敗嘗試，只是因為我希望這篇文章向人們展示在滲透測試期間思維過程是如何展開的。

在我嘗試使事情復雜化（即脫離所有 JOIN 和 FROM 子句）時，我使用了一個簡單的分號和注釋技巧 (;--)。計劃是首先檢索數據庫名稱，然后在此基礎上檢索表中的數據：

服務器上生成的 SQL 查詢如下：

無論如何，這當然行不通，原因有兩個：

第5行之后的所有內容都會因為注釋而被忽略，這不一定是限制性的，但我寧愿在 FROM 子句中執行我的 SQLi。

我收到以下錯誤：“綁定消息提供 1 個參數，但準備好的語句需要 0”。這是因為 name 變量被傳遞給準備好的語句，但第 8 行被忽略了，因此新的準備好的語句不需要該變量。

第四次嘗試

我在這里給出了從表中檢索數據的另一個早期嘗試，它使我更接近我的目標。在此之前我所知道的是，以下負載將被WAF 阻止：

注意：我添加了 LIMIT 和 OFFSET 關鍵字，以便從 table1 中僅檢索一行。LIMIT 表示我們只想要檢索一行，OFFSET 表示在開始檢索數據之前我們想要跳過多少行。在這種情況下，OFFSET 0 表示數據庫應該跳過 0 行并返回 table1 中的第一行。這對于逐一檢索表的所有行很有用。

WAF 繞過的第三種辦法

回顧從數據庫服務器產生的錯誤中檢索到的 SQL 查詢，我注意到可能不需要使用 FROM 子句。table1 表在使用 AS 關鍵字的查詢中別名為 t1，并且可以基于 t1 引用它的任何列。這樣就可以這樣查詢 table1 的 column1 列：

這可以很好地通過（錯誤配置的）Cloudflare WAF，因此 POST 請求正文中的有效負載可以這樣轉換：

服務器上的后續 SQL 查詢如下所示：

這可以正常工作，但限制是只能提取 table1（或 table2）中的數據，因為這些是服務器 SQL 查詢中唯一的別名表，繼續進行最后的成功嘗試。

最后一次嘗試

好吧，如果我想從數據庫中檢索任何我想要的數據，我不得不放棄WAF 繞過的第三種方法。此時，似乎沒有辦法避免使用FROM子句。而且，在不被Cloudflare的WAF檢測到的情況下，似乎也沒有辦法成功地將FROM子句隱藏到有效載荷中。似乎我正在尋找的答案不在SQL查詢中。我不得不后退一步。

進入 GraphQL

我們已經看到發送的請求的正文是一個 GraphQL 查詢，然后它被翻譯成一個 SQL 查詢。所以我的下一個嘗試是改變 GraphQL 查詢并設法隱藏其中的 FROM 子句，這將有望轉換為在服務器上工作的SQL查詢。

如上所述，GraphQL 查詢的結構類似于 JSON 對象。JSON 中的數據以名稱/值對存儲在字典中，它們都是字符串。GraphQL 查詢需要字符串鍵，但允許使用任意參數。這些規則適用于 GraphQL：

數據用逗號分隔；

花括號容納對象；

方括號包含數組；

因此一個GraphQL查詢參數可以看起來像以下任何一種方式：

這讓我想到：如果我將對象的值作為數組而不是字符串傳遞，后端服務器上的 SQL 查詢會發生什么。簡而言之，我想打破 SQL 注入查詢并將 FROM 子句移動到不同的對象以欺騙 Cloudflare。

進入

該請求繞過了WAF，我從數據庫中得到了一個錯誤，報錯是一個格式不正確的SQL查詢，并向我顯示了完整的SQL查詢結果。在注入點的查詢是這樣的：

注意 SELECT column1 后面的逗號 (,) 嗎？那是我繞過 SQLi 過濾的憑證。將 GraphQL 查詢參數的值作為數組傳遞會在后端 SQL 服務器中轉換為字符串。字符串只是由逗號和空格字符分隔的數組項的串聯！此時，SQL查詢是錯誤的，但我可以注釋掉逗號，并獲得一個有效的、繞過waff的請求，該請求從我選擇的任何數據庫表中檢索我想要的任何數據。

這是最終 POST 請求的正文：

以及在 SQL 服務器上生成的有效 SQL 查詢：

成功！

為了簡化表檢索過程，我用Python編寫了一個腳本來自動化這個過程。腳本的偽代碼如下所示：

這就是我如何利用 GraphQL 制作 SQL 注入，繞過配置錯誤的 Cloudflare WAF 實例，并能夠在后端檢索整個數據庫。正如我在開頭提到的，這種繞過技術的組合不適用于正確配置的 Cloudflare WAF。

緩解措施

緩解數據庫上 SQL 注入的最安全方法是準備好的語句。