關於web安全測試，目前主要有以下幾種攻擊方法：
1.XSS
2.SQL注入
3.跨目錄訪問
4.緩沖區溢出
5.cookies修改
6.Htth方法篡改（包括隱藏字段修改和參數修改）
7.CSRF
8.CRLF
9.命令行注入
今天主要講下SQL盲注。
一、SQL 盲注、發現數據庫錯誤模式、跨站點腳本編制
| 嚴重性: |
高 |
| 類型: |
應用程序級別測試 |
| WASC威脅分類: |
|
| CVE 引用: |
不適用 |
| 安全風險: |
1. 可能會查看、修改或刪除數據庫條目和表 ---SQL盲注 2. 可能會竊取或操縱客戶會話和 cookie，它們可能用於模仿合法用戶，從而使黑客能夠以該用戶身份查看或變更用戶記錄以及執行事務 ---跨站的腳本編制 |
發現數據庫錯誤模式、跨站點腳本編制都是此類行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 查詢、嵌入將在客戶端執行的 Javascript. 代碼、運行各種操作系統命令，等等。 建議過濾出所有以下字符：
[1] |（豎線符號）[2] & （& 符號）[3];（分號）[4] $（美元符號）[5] %（百分比符號）[6] @（at 符號）