The difference between PHP functions Addslashes and mysql_real_escape_string

From: http://www.jb51.net/article/49205.htm This article mainly introduces the differences between PHP functions Addslashes and Mysql_real_escape_string, and an Introduction to SQL injection vulnerability, A friend you need can refer to the following

First: Do not use mysql_escape_string, it has been deprecated, please use mysql_real_escape_string instead.

The difference between mysql_real_escape_string and addslashes is that:

Difference One:

Addslashes does not know anything about the MySQL connection character set. If you pass a string that contains an encoding other than the byte encoding to the MySQL connection you are using, it will happily escape all the bytes of the character ', ', \, and \x00. If you are using other characters that are different from 8-bit and UTF-8, the values of these bytes are not necessarily all representations of characters ', ', \, and \x00. The possible result is that MySQL receives these characters after the error occurs.

If you want to fix this bug, try using the Iconv function, convert the variable to UTF-16, and then escape using Addslashes.

This is one of the reasons for escaping without using addslashes.

Difference Two:

In contrast to Addslashes, mysql_real_escape_string also escapes \ r, \ n, and \x1a. It seems that these characters must be correctly told to MySQL, otherwise they will get the wrong query results.

This is another reason not to use addslashes for escaping.

Addslashes V.s. mysql_real_escape_string

In GBK, 0xbf27 is not a legal multi-character, but 0xbf5c is. In a single-byte environment, 0XBF27 is treated as 0XBF followed by 0x27 ('), while 0xbf5c is treated as 0XBF followed by 0x5c (\).

A single quotation mark escaped with a backslash prevents SQL injection attacks against MySQL from being effectively blocked. If you use Addslashes, then I (the attacker, the same) is very fortunate. I just inject some similar 0xbf27 and then addslashes it to 0xbf5c27, a valid multibyte character followed by a single quote. In other words, I can ignore your escape and successfully inject a single quotation mark. This is because 0XBF5C is treated as a single-byte character rather than as a double-byte.

In this demo, I'll use MySQL 5.0 and PHP's mysqli extension. If you want to try, make sure you use GBK.

Create a table that is named users:

The code is as follows:

CREATE TABLE  varchar (CHARACTERSETvarchar(  CHARACTERSETPRIMARYKEY(username));

The following code simulates the case when the query data is escaped using only addslashes (or MAGIC_QUOTES_GPC):
The code is as follows:

<?PHP$mysql=Array();$db=Mysqli_init();$db->real_connect (' localhost ', ' lorui ', ' lorui.com ', ' lorui_db ');/*SQL Injection Example*/$_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 users WHERE username = ' {$mysql [' username '} ' and password = ' {$mysql [' Password ']} '"; $result = $db->query ($sql); if ($result->num_rows) {/* succeeded*/}Else{/*failed*/}

Despite the use of addslashes, I can successfully log in without knowing the user name and password. I can easily exploit this vulnerability for SQL injection.

To avoid this vulnerability, use mysql_real_escape_string, prepare statements (Prepared statements, "parameterized queries") or any of the mainstream database abstraction class libraries.

The difference between PHP functions Addslashes and mysql_real_escape_string