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

測試時使用的Web應(yīng)用程序詳細(xì)信息

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

查詢的形成類似于 JSON 對象。應(yīng)用程序向 /graphql 端點(diǎn)發(fā)送 POST 請求。請求正文包含 GraphQL 查詢，如下所示：

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

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

觀察 1

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

這將返回“OK”：

這將返回"NOT OK"：

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

步驟如下：

• 我們有一組字符，稱為字母表。這組字符包括所有可能的字符，這些字符可以是我們試圖從數(shù)據(jù)庫中提取的數(shù)據(jù)的一部分。
• 假設(shè)資源是需要檢索的 SQL 資源。它可以是數(shù)據(jù)庫名稱、用戶名、任何表格中的單元格值等。
• 將逐字符檢索資源。我們試圖檢索的字符稱為 char。
• 我們遍歷字母表，并將每個字母與 char 進(jìn)行比較。
• 如果有匹配，我們記錄結(jié)果并移動到下一個字符。
• 最后，我們通過連接所有字符獲得了完整的資源。

觀察 2

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

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

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

• 可以看到用戶輸入被括在括號中，這條信息使有效負(fù)載的生成過程變得更加容易，因?yàn)槿藗冎垒斎氡仨毎c左括號匹配的右括號，以便結(jié)束 SQL 查詢有效。
• 用戶輸入反映在查詢中的多個位置（第 5、10、11 行），給我?guī)砺闊┑氖堑?5 行。如果是 X-MARK 僅反映在 WHERE 子句中的情況，事情會更容易。但在這種情況下，我必須確保我的輸入不會弄亂表 JOIN。這是必要的，以確保生成和查詢正確的表行，以便我可以獲得所需的數(shù)據(jù)。

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

第一次嘗試

我首先嘗試查找當(dāng)前數(shù)據(jù)庫的名稱。在 PostgreSQL 中執(zhí)行此操作的 SQL 查詢是：

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

WAF 繞過的第一種辦法

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

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

并且未被 WAF 檢測到。

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

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

但是，記住后端 SQL 查詢?nèi)绾伟?JOIN 子句（來自觀察2），我還在查詢中添加了一些額外的內(nèi)容，以確保 SQL 連接在后臺正確執(zhí)行。 POST 請求的正文如下所示：

服務(wù)器上的后續(xù) SQL 查詢?nèi)缦滤荆?/p>

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

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

第二次嘗試

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

經(jīng)過反復(fù)測試，我發(fā)現(xiàn)問題出在生成的服務(wù)器 SQL 查詢中的 FROM 子句中的空格。這導(dǎo)致我進(jìn)入第二個 WAF 繞過。

WAF 繞過的第二種辦法

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

變成了：

因此 POST 請求的結(jié)果正文變?yōu)椋?/p>

在服務(wù)器上的后續(xù)SQL查詢是這樣的：

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

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

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

第三次嘗試

我在這里給出 SQLi 的早期失敗嘗試，只是因?yàn)槲蚁Ｍ@篇文章向人們展示在滲透測試期間思維過程是如何展開的。

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

服務(wù)器上生成的 SQL 查詢?nèi)缦拢?/p>

無論如何，這當(dāng)然行不通，原因有兩個：

• 第5行之后的所有內(nèi)容都會因?yàn)樽⑨尪缓雎?，這不一定是限制性的，但我寧愿在 FROM 子句中執(zhí)行我的 SQLi。
• 我收到以下錯誤：“綁定消息提供 1 個參數(shù)，但準(zhǔn)備好的語句需要 0”。這是因?yàn)?name 變量被傳遞給準(zhǔn)備好的語句，但第 8 行被忽略了，因此新的準(zhǔn)備好的語句不需要該變量。

第四次嘗試

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

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

WAF 繞過的第三種辦法

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

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

服務(wù)器上的后續(xù) SQL 查詢?nèi)缦滤荆?/p>

這可以正常工作，但限制是只能提取 table1（或 table2）中的數(shù)據(jù)，因?yàn)檫@些是服務(wù)器 SQL 查詢中唯一的別名表，繼續(xù)進(jìn)行最后的成功嘗試。

最后一次嘗試

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

進(jìn)入 GraphQL

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

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

• 數(shù)據(jù)用逗號分隔；
• 花括號容納對象；
• 方括號包含數(shù)組；

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

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

進(jìn)入

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

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

這是最終 POST 請求的正文：

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

成功！

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

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

緩解措施

緩解數(shù)據(jù)庫上 SQL 注入的最安全方法是準(zhǔn)備好的語句。