Web系統常見(jiàn)安全漏洞及解決方案-SQL盲注

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

1.XSS

2.SQL注入

3.跨目錄訪(fǎng)問(wèn)

4.緩沖區溢出

5.cookies修改

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

7.CSRF

8.CRLF

9.命令行注入

今天主要講下SQL盲注。

一、SQL 盲注、發(fā)現數據庫錯誤模式、跨站點(diǎn)腳本編制

發(fā)現數據庫錯誤模式、跨站點(diǎn)腳本編制都是此類(lèi)行Bug

l          可能原因

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

l          技術(shù)描述

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

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

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

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

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

user = ' or 1=1 or ''=' password = foobar
生成的查詢(xún)如下：

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

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

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

l          受影響產(chǎn)品

該問(wèn)題可能會(huì )影響各種類(lèi)型的產(chǎn)品。

l          引用和相關(guān)鏈接

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

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

§             盲目 SQL 注入培訓模塊

二、修改建議

一般

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

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