PHP函數addslashes和mysql_real_escape_string的區別

標籤：

轉自：http://www.jb51.net/article/49205.htm 這篇文章主要介紹了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的表：

代碼如下:

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

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

<?php$mysql = array();$db = mysqli_init();$db->real_connect(‘localhost‘, ‘lorui‘, ‘lorui.com‘, ‘lorui_db‘);/* SQL注入樣本 */$_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，即“參數化查詢”）或者任意一款主流的資料庫抽象類別庫。

PHP函數addslashes和mysql_real_escape_string的區別