PHP函數 addslashes() 和 mysql_real_escape_string() 的區別，SQL注入攻擊分析

標籤：dsl   傳遞   use   轉義   wiki   from   bsp   rom   art   

首先：不要使用 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後面跟著0x27(‘)，同時0xbf5c被視為0xbf後面跟著0x5c(\)。

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

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

建立一個名為 users 的表：

CREATE TABLE users(username VARCHAR(32) CHARACTER SET GBK,password VARCHAR(32) CHARACTER SET GBK,PRIMARY KEY(username));

下面的代碼類比只使用 addslashes()（或magic_quotes_gpc） 對查詢資料進行轉義時的情況：

<?phpheader(‘Content-Type: text/html; charset=gbk‘);$mysql = array();$db = mysqli_init();$db->real_connect(‘localhost‘, ‘root‘, ‘root‘, ‘go-study‘);/* SQL注入樣本 */$_POST[‘username‘] = chr(0xbf) . chr(0x27) . ‘ OR username = username /*‘;$_POST[‘password‘] = ‘guess‘;$mysql[‘username‘] = addslashes($_POST[‘username‘]);$mysql[‘password‘] = addslashes($_POST[‘password‘]);$sql = "SELECT *FROM usersWHERE username = ‘{$mysql[‘username‘]}‘AND password = ‘{$mysql[‘password‘]}‘";write2($sql);$result = $db->query($sql);if ($result->num_rows) {/* 成功 */} else {/* 失敗 */}

儘管使用了addslashes()，我還是可以在不知道使用者名稱和密碼的情況下成功登入。我可以輕鬆的利用這個漏洞進行SQL注入。

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

PHP函數 addslashes() 和 mysql_real_escape_string() 的區別，SQL注入攻擊分析