SQL注入攻擊的種類與防范手段

觀察近來的一些安全事件及其后果， 安全專家們已經得到一個結論， 這些威脅主要是通過SQL注入造成的。 雖然前面有許多文章討論了SQL注入， 但今天所討論的內容也許可幫助你檢查自己的服務器， 并采取相應防范措施。

　　SQL注入攻擊的種類

　　知彼知己， 方可取勝。 首先要清楚SQL注入攻擊有哪些種類。

　　1.沒有正確過濾轉義字符

　　在用戶的輸入沒有為轉義字符過濾時， 就會發(fā)生這種形式的注入式攻擊， 它會被傳遞給一個SQL語句。 這樣就會導致應用程序的終端用戶對數據庫上的語句實施操縱。 比方說， 下面的這行代碼就會演示這種漏洞：

　　statement := "SELECT * FROM users WHERE name = '" + userName + "'; "

　　這種代碼的設計目的是將一個特定的用戶從其用戶表中取出， 但是， 如果用戶名被一個惡意的用戶用一種特定的方式偽造， 這個語句所執(zhí)行的操作可能就不僅僅是代碼的作者所期望的那樣了。 例如， 將用戶名變量(即username)設置為：

　　a' or 't'='t， 此時原始語句發(fā)生了變化：

　　SELECT * FROM users WHERE name = 'a' OR 't'='t';

　　如果這種代碼被用于一個認證過程， 那么這個例子就能夠強迫選擇一個合法的用戶名， 因為賦值't'='t永遠是正確的。

　　在一些SQL服務器上， 如在SQL　Server中， 任何一個SQL命令都可以通過這種方法被注入， 包括執(zhí)行多個語句。 下面語句中的username的值將會導致刪除“users”表， 又可以從“data”表中選擇所有的數據(實際上就是透露了每一個用戶的信息)。

　　a'; DROP TABLE users; SELECT * FROM data WHERE name LIKE '%

　　這就將最終的SQL語句變成下面這個樣子：

　　SELECT * FROM users WHERE name = 'a'; DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%';

　　其它的SQL執(zhí)行不會將執(zhí)行同樣查詢中的多個命令作為一項安全措施。 這會防止攻擊者注入完全獨立的查詢， 不過卻不會阻止攻擊者修改查詢。

　　2.Incorrect type handling

　　如果一個用戶提供的字段并非一個強類型， 或者沒有實施類型強制， 就會發(fā)生這種形式的攻擊。 當在一個SQL語句中使用一個數字字段時， 如果程序員沒有檢查用戶輸入的合法性(是否為數字型)就會發(fā)生這種攻擊。 例如：

　　statement := "SELECT * FROM data WHERE id = " + a_variable + "; "

　　從這個語句可以看出， 作者希望a_variable是一個與“id”字段有關的數字。 不過， 如果終端用戶選擇一個字符串， 就繞過了對轉義字符的需要。 例如， 將a_variable設置為:1; DROP TABLE users， 它會將“users”表從數據庫中刪除， SQL語句變成：SELECT * FROM DATA WHERE id = 1; DROP TABLE users;

　　3.數據庫服務器中的漏洞

　　有時， 數據庫服務器軟件中也存在著漏洞， 如MYSQL服務器中mysql_real_escape_string()函數漏洞。 這種漏洞允許一個攻擊者根據錯誤的統(tǒng)一字符編碼執(zhí)行一次成功的SQL注入式攻擊。

　　4.盲目SQL注入式攻擊

　　當一個Web應用程序易于遭受攻擊而其結果對攻擊者卻不見時， 就會發(fā)生所謂的盲目SQL注入式攻擊。 有漏洞的網頁可能并不會顯示數據， 而是根據注入到合法語句中的邏輯語句的結果顯示不同的內容。 這種攻擊相當耗時， 因為必須為每一個獲得的字節(jié)而精心構造一個新的語句。 但是一旦漏洞的位置和目標信息的位置被確立以后， 一種稱為Absinthe的工具就可以使這種攻擊自動化。

　　5.條件響應

　　注意， 有一種SQL注入迫使數據庫在一個普通的應用程序屏幕上計算一個邏輯語句的值：

　　SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1

　　這會導致一個標準的面面， 而語句

　　SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2在頁面易于受到SQL注入式攻擊時， 它有可能給出一個不同的結果。 如此這般的一次注入將會證明盲目的SQL注入是可能的， 它會使攻擊者根據另外一個表中的某字段內容設計可以評判真?zhèn)蔚恼Z句。

　　6.條件性差錯

　　如果WHERE語句為真， 這種類型的盲目SQL注入會迫使數據庫評判一個引起錯誤的語句， 從而導致一個SQL錯誤。 例如：

　　SELECT 1/0 FROM users WHERE username='Ralph'。 顯然， 如果用戶Ralph存在的話， 被零除將導致錯誤。

　　7.時間延誤

　　時間延誤是一種盲目的SQL注入， 根據所注入的邏輯， 它可以導致SQL引擎執(zhí)行一個長隊列或者是一個時間延誤語句。 攻擊者可以衡量頁面加載的時間， 從而決定所注入的語句是否為真。

　　以上僅是對SQL攻擊的粗略分類。 但從技術上講， 如今的SQL注入攻擊者們在如何找出有漏洞的網站方面更加聰明， 也更加全面了。 出現了一些新型的SQL攻擊手段。 黑客們可以使用各種工具來加速漏洞的利用過程。 我們不妨看看the Asprox Trojan這種木馬， 它主要通過一個發(fā)布郵件的僵尸網絡來傳播， 其整個工作過程可以這樣描述：首先， 通過受到控制的主機發(fā)送的垃圾郵件將此木馬安裝到電腦上， 然后， 受到此木馬感染的電腦會下載一段二進制代碼， 在其啟動時， 它會使用搜索引擎搜索用微軟的ASP技術建立表單的、有漏洞的網站。 搜索的結果就成為SQL注入攻擊的靶子清單。 接著， 這個木馬會向這些站點發(fā)動SQL注入式攻擊， 使有些網站受到控制、破壞。 訪問這些受到控制和破壞的網站的用戶將會受到欺騙， 從另外一個站點下載一段惡意的JavaScript代碼。 最后， 這段代碼將用戶指引到第三個站點， 這里有更多的惡意軟件， 如竊取口令的木馬。

　　以前， 我們經常警告或建議Web應用程序的程序員們對其代碼進行測試并打補丁， 雖然SQL注入漏洞被發(fā)現和利用的機率并不太高。 但近來攻擊者們越來越多地發(fā)現并惡意地利用這些漏洞。 因此， 在部署其軟件之前， 開發(fā)人員應當更加主動地測試其代碼， 并在新的漏洞出現后立即對代碼打補丁。

　　防御和檢查SQL注入的手段

　　1.使用參數化的過濾性語句

　　要防御SQL注入， 用戶的輸入就絕對不能直接被嵌入到SQL語句中。 恰恰相反， 用戶的輸入必須進行過濾， 或者使用參數化的語句。 參數化的語句使用參數而不是將用戶輸入嵌入到語句中。 在多數情況中， SQL語句就得以修正。 然后， 用戶輸入就被限于一個參數。 下面是一個使用Java和JDBC API例子：

　　PreparedStatement prep = conn.prepareStatement("SELECT * FROM USERS WHERE PASSWORD=?");

　　prep.setString(1, pwd);

　　總體上講， 有兩種方法可以保證應用程序不易受到SQL注入的攻擊， 一是使用代碼復查， 二是強迫使用參數化語句的。 強迫使用參數化的語句意味著嵌入用戶輸入的SQL語句在運行時將被拒絕。 不過， 目前支持這種特性的并不多。 如H2 數據庫引擎就支持。

　　2.還要避免使用解釋程序， 因為這正是黑客們借以執(zhí)行非法命令的手段。

　　3.防范SQL注入， 還要避免出現一些詳細的錯誤消息， 因為黑客們可以利用這些消息。 要使用一種標準的輸入確認機制來驗證所有的輸入數據的長度、類型、語句、企業(yè)規(guī)則等。

　　4.使用專業(yè)的漏洞掃描工具。 但防御SQL注入攻擊也是不夠的。 攻擊者們目前正在自動搜索攻擊目標并實施攻擊。 其技術甚至可以輕易地被應用于其它的Web架構中的漏洞。 企業(yè)應當投資于一些專業(yè)的漏洞掃描工具， 如大名鼎鼎的Acunetix的Web漏洞掃描程序等。 一個完善的漏洞掃描程序不同于網絡掃描程序， 它專門查找網站上的SQL注入式漏洞。 最新的漏洞掃描程序可以查找最新發(fā)現的漏洞。

　　5.最后一點， 企業(yè)要在Web應用程序開發(fā)過程的所有階段實施代碼的安全檢查。 首先， 要在部署Web應用之前實施安全測試， 這種措施的意義比以前更大、更深遠。 企業(yè)還應當在部署之后用漏洞掃描工具和站點監(jiān)視工具對網站進行測試。

　　Web安全拉警報已經響起， 安全形式異常嚴峻， 企業(yè)絕對不應當草率從事。 安全重于泰山!