PHP中addslashes與mysql_real_escape_string有什么區別

這篇文章給大家介紹PHP中addslashes與mysql_real_escape_string有什么區別，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

首先：不要使用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有什么區別就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。