常用的SQL注入攻擊方法總結

1. 沒有正確過濾逸出字元

在使用者的輸入沒有逸出字元過濾時，就會發生這種形式的注入或攻擊，它會被傳遞給一個SQL語句。這樣就會導致應用程式的終端使用者對資料庫上的語句實施操作。比方說，下面的這行代碼就會示範這種漏洞：

代碼如下	複製代碼
"SELECT * FROM users WHERE name = ' " + userName + " ' ;"

這種代碼的設計目的是將一個特定的使用者從其使用者表中取出，但是，如果使用者名稱被一個惡意的使用者用一種特定的方式偽造，這個語句所執行的操作可能就不僅僅是代碼的作者所期望的那樣了。例如，將使用者名稱變數（即username）設定為：a' or 't' = 't，此時原始語句發生了變化：

代碼如下	複製代碼
SELECT * FROM users WHERE name = 'a' OR 't' = 't';

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

在一些SQL伺服器上，如在SQL Server中，任何一個SQL命令都可以通過這種方法被注入，包括執行多個語句。下面語句中的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執行不會將執行同樣查詢中的多個命令作為一項安全措施。這會防止攻擊者注入完全獨立的查詢，不過卻不會阻止攻擊者修改查詢。

2. Incorrect type handling

如果一個使用者提供的欄位並非一個強型別，或者沒有實施類型強制，就會發送這種形式的攻擊。當在一個SQL語句中使用一個數字欄位時，如果程式員沒有檢查使用者輸入的合法性（是否為數字型）就會發生這種攻擊。例如：

代碼如下	複製代碼
"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()函數漏洞。這種漏洞允許一個攻擊者根據錯誤的統一字元編碼執行一次成功的SQL注入式攻擊。

4. 盲目SQL注入式攻擊

當一個Web應用程式易於遭受攻擊而其結果對攻擊者卻不見時，就會發生所謂的盲目SQL注入式攻擊。有漏洞的網頁可能並不會顯示資料，而是根據注入到合法語句中的邏輯語句的結果顯示不同的內容。這種攻擊相當耗時，因為必須為每一個獲得的位元組而精心構造一個新的語句。但是一旦漏洞的位置和目標資訊的位置被確立以後，一種稱為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注入是可能的，它會使攻擊者根據另外一個表中的某欄位內容設計可以評判真偽的語句。

6. 條件性差錯

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

代碼如下	複製代碼
SELECT 1/0 FROM users WHERE username='Ralph'。

顯然，如果使用者Ralph存在的話，被零除將導致錯誤。

7. 時間延誤

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

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

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

例如，某些人可能會在登陸視窗使用這種方法繞開登陸。如果你的查詢使用者名稱和密碼的形式類似這樣子：

代碼如下	複製代碼
[code='sql'] SELECT * FROM users WHERE username = {username} AND password = {password } [/code] 那麼使用者可以使用任意的使用者名稱，使用這個密碼： [code='sql']' OR ''=''[/code] 從而使得你的驗證使用者名稱密碼的MySQL查詢變成： [code='sql'] SELECT * FROM users WHERE username = 'anyuser' AND password = '' OR ''='' [/code]

由於空串總是等於空串，所以查詢條件永真。因此可以看到，MySQL注入的風險還是很大的，因為攻擊者可以看到那些本來應該通過登陸才能訪問的資料。防止你的網站受到注入式攻擊是非常重要的。幸運的是，PHP可以協助我們防止注入式攻擊。
MySQL將會返回表中的所有行，根據你的程式邏輯，可能會導致全部使用者都登陸了，因為他們都被匹配到了。現在，大部分情況下，人們會開啟magic_quotes_gpc選項(也是PHP的預設情況)，這樣的配置將會自動添加反斜線，轉義全部'(單引號)，"(雙引號)，(反斜線)和Null 字元。但事情並不是這麼簡單就能解決，因為並不是所有的會導致風險的字元都被轉義了。PHP有一個函數可以轉義全部可能帶來多餘SQL子句的MySQL字元。這個函數就是mysql_real_escape_string()。
使用這個函數的時候要小心，因為你可能已經開啟了magic_quotes_gpc選項，這時候使用mysql_real_escape_string()會導致第二次轉義。下面這個函數避免了這個問題，首先判斷
magic_quotes_gpc選項是否開啟，然後再決定是否執行mysql_real_escape_string()。
[code='php']

代碼如下	複製代碼
//給變數加引號以保證安全 function quote_smart($value) { $link=mysql_connect('mysql_host','mysql_user','mysql_password'); //去轉義 if(get_magic_quotes_gpc()) { $value=stripslashes($value); } //給所有非數字加引號 if(!is_numeric($value)) { $value="'".mysql_real_escape_string($value,$link)."'"; } return $value; } ?>

[/code]
需要注意的是，quote_smart()函數會自動給字串加引號，因此你不需要自己加。
另外需要注意，因為不同的MySQL版本對於過濾的要求不一樣，mysql_real_escape_string()需要一個MySQL串連才能工作，因此必須第二個參數傳入一個MySQL串連。在本機安裝MySQL的情況，可以省略，但是如果本機沒有裝MySQL，或者遠端連線到MySQL，則這個參數必不可少，否則mysql_real_escape_string()將返回一個Null 字元串。