小说阅读网站,官场小说排行榜

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

正確的WAF配置對(duì)網(wǎng)絡(luò)安全是如此重要

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

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

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

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

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

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

觀察 1

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

這將返回“OK”：

這將返回"NOT OK"：

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

步驟如下：

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

觀察 2

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

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

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

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

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

第一次嘗試

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

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

WAF 繞過的第一種辦法

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

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

并且未被 WAF 檢測到。

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

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

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

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

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

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

第二次嘗試

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

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

WAF 繞過的第二種辦法

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

變成了：

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

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

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

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

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

第三次嘗試

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

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

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

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

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

第四次嘗試

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

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

WAF 繞過的第三種辦法

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

這可以很好地通過（錯(cuò)誤配置的）Cloudflare WAF，因此 POST 請(qǐng)求正文中的有效負(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 繞過的第三種方法。此時(shí)，似乎沒有辦法避免使用FROM子句。而且，在不被Cloudflare的WAF檢測到的情況下，似乎也沒有辦法成功地將FROM子句隱藏到有效載荷中。似乎我正在尋找的答案不在SQL查詢中。我不得不后退一步。

進(jìn)入 GraphQL

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

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

數(shù)據(jù)用逗號(hào)分隔；
花括號(hào)容納對(duì)象；
方括號(hào)包含數(shù)組；

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

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

進(jìn)入

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

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

這是最終 POST 請(qǐng)求的正文：

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

成功！

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

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

緩解措施

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

網(wǎng)頁名稱：正確的WAF配置對(duì)網(wǎng)絡(luò)安全是如此重要
文章位置：http://fisionsoft.com.cn/article/djedpcc.html