Web系統常見安全漏洞及解決方案-SQL盲注

關于web安全測試，目前主要有以下幾種攻擊方法：

1.XSS

2.SQL注入

3.跨目錄訪問

4.緩沖區溢出

5.cookies修改

6.Htth方法篡改（包括隱藏字段修改和參數修改）

7.CSRF

8.CRLF

9.命令行注入

今天主要講下SQL盲注。

一、SQL 盲注、發現數據庫錯誤模式、跨站點腳本編制

發現數據庫錯誤模式、跨站點腳本編制都是此類行Bug

l          可能原因

1.       未對用戶輸入正確執行危險字符清理 

l          技術描述

AppScan 在測試響應中發現到“SQL 注入”以外的攻擊所觸發的“數據庫錯誤”。
雖然不確定，但這個錯誤可能表示應用程序有“SQL 注入”漏洞。

Web 應用程序通常在后端使用數據庫，以與企業數據倉庫交互。查詢數據庫事實上的標準語言是 SQL（各大數據庫供應商都有自己的不同版本）。Web 應用程序通常會獲取用戶輸入（取自 HTTP 請求），將它并入 SQL 查詢中，然后發送到后端數據庫。接著應用程序便處理查詢結果，有時會向用戶顯示結果。
如果應用程序對用戶（攻擊者）的輸入處理不夠小心，攻擊者便可以利用這種操作方式。在此情況下，攻擊者可以注入惡意的數據，當該數據并入 SQL 查詢中時，就將查詢的原始語法更改得面目全非。例如，如果應用程序使用用戶的輸入（如用戶名和密碼）來查詢用戶帳戶的數據庫表，以認證用戶，而攻擊者能夠將惡意數據注入查詢的用戶名部分（和/或密碼部分），查詢便可能更改成完全不同的數據復制查詢，可能是修改數據庫的查詢，或在數據庫服務器上運行 Shell 命令的查詢。
一般而言，攻擊者會分步實現這個目標。他會先學習 SQL 查詢的結構，然后使用該知識來阻撓查詢（通過注入更改查詢語法的數據），使執行的查詢不同于預期。假設相關查詢是：
SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass'

其中 $user 和 $pass 是用戶輸入（從調用構造查詢的腳本的 HTTP 請求收集而來 － 可能是來自 GET 請求查詢參數，也可能是來自 POST 請求主體參數）。此查詢的一般用法，其值為 $user=john、$password=secret123。形成的查詢如下：SELECT COUNT(*) FROM accounts WHERE username='john' AND password='secret123'

如果數據庫中沒有這個用戶密碼配對，預期的查詢結果便是 0，如果此類配對存在（也就是數據庫中有名稱為“john”的用戶，且其密碼為“secret123”），結果便是 >0。這是應用程序的基本認證機制。但攻擊者可以用下列方式來更改此查詢：
攻擊者可以提供單引號字符（'）所組成的輸入，使數據庫發出錯誤消息，其中通常包含關于 SQL 查詢的有價值的信息。攻擊者只需在發送的請求中包含用戶值 '，并在密碼中包含任何值（如 foobar）。結果便是下列（格式錯誤）的 SQL 查詢：SELECT COUNT(*) FROM accounts WHERE username=''' AND password='foobar'

這可能會產生以下錯誤消息（取決于后端所使用的特定數據庫）：查詢表達式 'username = ''' AND password = 'foobar'' 中發生語法錯誤（遺漏運算符）。
這時攻擊者便得知查詢是根據表達式 username='$user' AND password='$pass' 來構建的。利用手邊的 SQL 查詢時需要這一關鍵信息。攻擊者了解查詢的格式后，下一步只需使用：

user = ' or 1=1 or ''=' password = foobar
生成的查詢如下：

SELECT COUNT(*) FROM accounts WHERE username='' or 1=1 or ''='' AND password='foobar'
這表示查詢（在 SQL 數據庫中）對于“accounts”表的每項記錄都會返回 TRUE，因為 1=1 表達式永遠為真。因此，查詢會返回“accounts”中的記錄數量，于是用戶（攻擊者）也會被視為有效。這個探測方法有若干變體，例如，發送 '; or \'（您應該記住，幾乎所有供應商都有他們自己唯一的 SQL“版本”。具體地說，發送 ' having 1=1，也會生成錯誤消息，此消息會泄露有關列名稱的信息。在某些情況下，用戶輸入不會并入字符串上下文（用單引號括�。�，而是并入數字上下文，換言之，就是依現狀嵌入。因此，在這種情況下，可以使用輸入字符串 1 having 1=1。
* 盲目 SQL 注入技術：  

降低 SQL 注入攻擊風險的一般方式，是禁止詳細的 SQL 錯誤消息，攻擊者通常便利用這些消息（如上述示例所說明），輕易找出容易遭受“SQL 注入”的腳本。
這個（以遮蓋獲取安全）解決方案可以利用稱為“盲目 SQL 注入”的技術來略過，黑客不需要依賴返回 SQL 錯誤消息，便能找出容易遭受“SQL 注入”的腳本。

這項技術需要發送易受攻擊的參數（被嵌入在 SQL 查詢中的參數）已被修改的請求，將參數修改成，使響應指出是否在 SQL 查詢上下文中使用數據。這項修改包括搭配原始字符串來使用 AND Boolean 表達式，使它一時得出 true，一時得出 false。在一種情況中，最終結果應該與原始結果相同（例如：登錄成功），在另一情況中，結果應該不同（例如：登錄失�。�。在某些少見的情況中，得出 true 的 OR 表達式也很有用。
如果原始數據是數字，可以耍較簡單的花招。原始數據（如 123）可以在一個請求中替換為 0+123，在另一個請求中替換為 456+123。第一個請求的結果應該與原始結果相同，第二個請求的結果應該不同（因為得出的數字是 579）。在某些情況中，我們仍需要上面所說明的攻擊版本（使用 AND 和 OR），但并不轉義字符串上下文。
盲目 SQL 注入背后的概念是，即使未直接收到數據庫的數據（以錯誤消息或泄漏信息的形式），也可能抽取數據庫中的數據，每次一個位，或以惡意方式修改查詢。觀念在于，應用程序行為（結果與原始結果相同，或結果與原始結果不同）可以提供關于所求值（已修改）之查詢的單位元相關信息，也就是說，攻擊者有可能規劃出以應用程序行為（相同/不同于原始行為）的形式來影響其求值（單位元）的 SQL Boolean 表達式。

l          受影響產品

該問題可能會影響各種類型的產品。

l          引用和相關鏈接

§ “Web 應用程序分解與 ODBC 錯誤消息”（作者：David Litchfield）：

§             “搭配 SQL 注入使用二分搜索法”（作者：Sverre H. Huseby）

§             盲目 SQL 注入培訓模塊

二、修改建議

一般

若干問題的補救方法在于對用戶輸入進行清理。
通過驗證用戶輸入未包含危險字符，便可能防止惡意的用戶導致應用程序執行計劃外的任務，例如：啟動任意 SQL 查詢、嵌入將在客戶端執行的 Javascript. 代碼、運行各種操作系統命令，等等。
建議過濾出所有以下字符：

[1] |（豎線符號）[2] & （& 符號）[3];（分號）[4] $（美元符號）[5] %（百分比符號）[6] @（at 符號）[7] '（單引號）[8] "（引號）[9] \'（反斜杠轉義單引號）[10] \"（反斜杠轉義引號）[11] <>