這篇文章主要介紹了PHP函數addslashes和mysql_real_escape_string的區別,以及一個SQL注入漏洞介紹,需要的朋友可以參考下。

首先：不要使用mysql_escape_string，它已被棄用，請使用mysql_real_escape_string代替它。

mysql_real_escape_string和addslashes的區別在于：

區別一：

addslashes不知道任何有關MySQL連接的字符集。如果你給所使用的MySQL連接傳遞一個包含字節編碼之外的其他編碼的字符串，它會很愉快地把所有值為字符‘、“、/和/x00的字節進行轉義。如果你正在使用不同于8位和UTF-8的其它字符，這些字節的值不一定全部都是表示字符‘、“、/和/x00。可能造成的結果是，MySQL接收這些字符后出現錯誤。

如果要修正這個bug，可嘗試使用iconv函數，將變量轉為UTF-16，然后再使用addslashes進行轉義。

這是不使用addslashes進行轉義的原因之一。

區別二：

與addslashes對比，mysql_real_escape_string同時還對/r、/n和/x1a進行轉義。看來，這些字符必須正確地告訴MySQL，否則會得到錯誤的查詢結果。

這是不使用addslashes進行轉義的另一個原因。

addslashes V.S. mysql_real_escape_string

在GBK里，0xbf27不是一個合法的多字符字符，但0xbf5c卻是。在單字節環境里，0xbf27被視為0xbf后面跟著0×27(‘)，同時0xbf5c被視為0xbf后面跟著0x5c(/)。

一個用反斜杠轉義的單引號，是無法有效阻止針對MySQL的SQL注入攻擊的。如果你使用addslashes，那么，我（攻擊者，下同）是很幸運的。我只要注入一些類似0xbf27，然后addslashes將它修改為0xbf5c27，一個合法的多字節字符后面接著一個單引號。換句話說，我可以無視你的轉義，成功地注入一個單引號。這是因為0xbf5c被當作單字節字符，而非雙字節。

在這個演示中，我將使用MySQL 5.0和PHP的mysqli擴展。如果你想嘗試，請確保你使用GBK。

創建一個名為users的表：

1. CREATE TABLE users( 
2.  username VARCHAR(32) CHARACTER SET GBK, 
3.  password VARCHAR(32) CHARACTER SET GBK, 
4.  PRIMARY KEY(username) 
5. ); 

下面的代碼模擬只使用addslashes（或magic_quotes_gpc）對查詢數據進行轉義時的情況：

1. <?php 
2. $mysql = array(); 
3. $db = mysqli_init(); 
4. $db->real_connect('localhost', 'lorui', 'lorui.com', 'lorui_db'); 
5. /* SQL注入示例 */ 
6. $_POST['username'] = chr(0xbf) . chr(0×27) . ‘ OR username = username /*'; $_POST['password'] = ‘guess'; $mysql['username'] = addslashes($_POST['username']); $mysql['password'] = addslashes($_POST['password']); $sql = “SELECT * FROM users WHERE username = ‘{$mysql['username']}' AND password = ‘{$mysql['password']}'”; $result = $db->query($sql); if ($result->num_rows) { /* 成功 */ } else { /* 失敗 */ } 

盡管使用了addslashes，我還是可以在不知道用戶名和密碼的情況下成功登錄。我可以輕松的利用這個漏洞進行SQL注入。

要以免這種漏洞，使用mysql_real_escape_string、準備語句（Prepared Statements，即“參數化查詢”）或者任意一款主流的數據庫抽象類庫。