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

https://hacker.bz/t/entry/15597-%E6%A8%99%E9%A1%8C%EF%BC%9A%E6%AD%A3%E7%A2%BA%E7%9A%84waf-%E9%85%8D%E7%BD%AE%E5%B0%8D%E7%B6%B2%E7%B5%A1%E5%AE%89%E5%85%A8%E6%98%AF%E5%A6%82%E6%AD%A4%E9%87%8D%E8%A6%81/

Followers

有研究人員在安全測試時，繞過了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 請求的正文：