SQL 注入是PHP應(yīng)用中最常見的漏洞之一。事實上令人驚奇的是，開發(fā)者要同時犯兩個錯誤才會引發(fā)一個SQL注入漏洞，一個是沒有對輸入的數(shù)據(jù)進行過濾（過濾輸入），還有一個是沒有對發(fā)送到數(shù)據(jù)庫的數(shù)據(jù)進行轉(zhuǎn)義（轉(zhuǎn)義輸出）。這兩個重要的步驟缺一不可，需要同時加以特別關(guān)注以減少程序錯誤。

對于攻擊者來說，進行SQL注入攻擊需要思考和試驗，對數(shù)據(jù)庫方案進行有根有據(jù)的推理非常有必要（當然假設(shè)攻擊者看不到你的源程序和數(shù)據(jù)庫方案），考慮以下簡單的登錄表單：

CODE:

<form action='/login.php' method='POST'>

<p>Username: <input type='text' name='username' /></p>

<p>Password: <input type='password' name='password' /></p>

<p><input type='submit' value='Log In' /></p>

</form>

圖 3-1 給出了該表單在瀏覽器中的顯示。

作為一個攻擊者，他會從推測驗證用戶名和密碼的查詢語句開始。通過查看源文件，他就能開始猜測你的習(xí)慣。

圖 3-1. 登錄表單在瀏覽器中的顯示

命名習(xí)慣。通常會假設(shè)你表單中的字段名為與數(shù)據(jù)表中的字段名相同。當然，確保它們不同未必是一個可靠的安全措施。

第一次猜測，一般會使用下面例子中的查詢：

CODE:

<?php

$password_hash = md5($_POST[’password’]);

$sql = 'SELECT count(*)

FROM users

WHERE username = ’{$_POST[’username’]}’

AND password = ’$password_hash’';

?>

使用用戶密碼的MD5值原來是一個通行的做法，但現(xiàn)在并不是特別安全了。最近的研究表明MD5算法有缺陷，而且大量MD5數(shù)據(jù)庫降低了MD5反向破解的難度。請訪問http://md5.rednoize.com/ 查看演示。

譯注：原文如此，山東大學(xué)教授王小云的研究表明可以很快的找到MD5的“碰撞”，就是可以產(chǎn)生相同的MD5值的不同兩個文件和字串。MD5是信息摘要算法，而不是加密算法，反向破解也就無從談起了。不過根據(jù)這個成果，在上面的特例中，直接使用md5是危險的。

最好的保護方法是在密碼上附加一個你自己定義的字符串，例如：

CODE:

<?php

$salt = ’SHIFLETT’;

$password_hash = md5($salt . md5($_POST[’password’] . $salt));

?>

當然，攻擊者未必在第一次就能猜中，他們常常還需要做一些試驗。有一個比較好的試驗方式是把單引號作為用戶名錄入，原因是這樣可能會暴露一些重要信息。有很多開發(fā)人員在Mysql語句執(zhí)行出錯時會調(diào)用函數(shù)mysql_error()來報告錯誤。見下面的例子：

CODE:

<?php

mysql_query($sql) or exit(mysql_error());

?>

雖然該方法在開發(fā)中十分有用，但它能向攻擊者暴露重要信息。如果攻擊者把單引號做為用戶名，mypass做為密碼，查詢語句就會變成：

CODE:

<?php

$sql = 'SELECT *

FROM users

WHERE username = ’’’

AND password = ’a029d0df84eb5549c641e04a9ef389e5’';

?>

當該語句發(fā)送到MySQL后，系統(tǒng)就會顯示如下錯誤信息：

You have an error in your SQL syntax. Check the manual that corresponds to your

MySQL server version for the right syntax to use near ’WHERE username = ’’’ AND

password = ’a029d0df84eb55

不費吹灰之力，攻擊者已經(jīng)知道了兩個字段名(username和password)以及他們出現(xiàn)在查詢中的順序。除此以外，攻擊者還知道了數(shù)據(jù)沒有正確進行過濾（程序沒有提示非法用戶名）和轉(zhuǎn)義（出現(xiàn)了數(shù)據(jù)庫錯誤），同時整個WHERE條件的格式也暴露了，這樣，攻擊者就可以嘗試操縱符合查詢的記錄了。

在這一點上，攻擊者有很多選擇。一是嘗試填入一個特殊的用戶名，以使查詢無論用戶名密碼是否符合，都能得到匹配：

myuser’ or ’foo’ = ’foo’ --

假定將mypass作為密碼，整個查詢就會變成：

CODE:

<?php

$sql = 'SELECT *

FROM users

WHERE username = ’myuser’ or ’foo’ = ’foo’ --

AND password = ’a029d0df84eb5549c641e04a9ef389e5’';

?>

由于中間插入了一個SQL注釋標記，所以查詢語句會在此中斷。這就允許了一個攻擊者在不知道任何合法用戶名和密碼的情況下登錄。

如果知道合法的用戶名，攻擊者就可以該用戶(如chris)身份登錄：

chris’ --

只要chris是合法的用戶名，攻擊者就可以控制該帳號。原因是查詢變成了下面的樣子：

CODE:

<?php

$sql = 'SELECT *

FROM users

WHERE username = ’chris’ --

AND password = ’a029d0df84eb5549c641e04a9ef389e5’';

?>

幸運的是，SQL注入是很容易避免的。正如第一章所提及的，你必須堅持過濾輸入和轉(zhuǎn)義輸出。

雖然兩個步驟都不能省略，但只要實現(xiàn)其中的一個就能消除大多數(shù)的SQL注入風(fēng)險。如果你只是過濾輸入而沒有轉(zhuǎn)義輸出，你很可能會遇到數(shù)據(jù)庫錯誤（合法的數(shù)據(jù)也可能影響SQL查詢的正確格式），但這也不可靠，合法的數(shù)據(jù)還可能改變SQL語句的行為。另一方面，如果你轉(zhuǎn)義了輸出，而沒有過濾輸入，就能保證數(shù)據(jù)不會影響SQL語句的格式，同時也防止了多種常見SQL注入攻擊的方法。

當然，還是要堅持同時使用這兩個步驟。過濾輸入的方式完全取決于輸入數(shù)據(jù)的類型（見第一章的示例），但轉(zhuǎn)義用于向數(shù)據(jù)庫發(fā)送的輸出數(shù)據(jù)只要使用同一個函數(shù)即可。對于MySQL用戶，可以使用函數(shù)mysql_real_escape_string( )：

CODE:

<?php

$clean = array();

$mysql = array();

$clean[’last_name’] = 'O’Reilly';

$mysql[’last_name’] = mysql_real_escape_string($clean[’last_name’]);

$sql = 'INSERT

INTO user (last_name)

VALUES (’{$mysql[’last_name’]}’)';

?>

盡量使用為你的數(shù)據(jù)庫設(shè)計的轉(zhuǎn)義函數(shù)。如果沒有，使用函數(shù)addslashes( )是最終的比較好的方法。

當所有用于建立一個SQL語句的數(shù)據(jù)被正確過濾和轉(zhuǎn)義時，實際上也就避免了SQL注入的風(fēng)險。

CODE:

如果你正在使用支持參數(shù)化查詢語句和占位符的數(shù)據(jù)庫操作類（如PEAR::DB, PDO等），你就會多得到一層保護。見下面的使用PEAR::DB的例子：

CODE:

<?php

$sql = ’INSERT

INTO user (last_name)

VALUES (?)’;

$dbh->query($sql, array($clean[’last_name’]));

?>

CODE:

由于在上例中數(shù)據(jù)不能直接影響查詢語句的格式，SQL注入的風(fēng)險就降低了。PEAR::DB會自動根據(jù)你的數(shù)據(jù)庫的要求進行轉(zhuǎn)義，所以你只需要過濾輸出即可。

如果你正在使用參數(shù)化查詢語句，輸入的內(nèi)容就只會作為數(shù)據(jù)來處理。這樣就沒有必要進行轉(zhuǎn)義了，盡管你可能認為這是必要的一步（如果你希望堅持轉(zhuǎn)義輸出習(xí)慣的話）。實際上，這時是否轉(zhuǎn)義基本上不會產(chǎn)生影響，因為這時沒有特殊字符需要轉(zhuǎn)換。在防止SQL注入這一點上，參數(shù)化查詢語句為你的程序提供了強大的保護。

譯注：關(guān)于SQL注入，不得不說的是現(xiàn)在大多虛擬主機都會把magic_quotes_gpc選項打開，在這種情況下所有的客戶端GET和POST的數(shù)據(jù)都會自動進行addslashes處理，所以此時對字符串值的SQL注入是不可行的，但要防止對數(shù)字值的SQL注入，如用intval()等函數(shù)進行處理。但如果你編寫的是通用軟件，則需要讀取服務(wù)器的magic_quotes_gpc后進行相應(yīng)處理。