Differences between PHP functions addslashes and mysql_real_escape_string

First, do not use mysql_escape_string. It has been discarded. Use mysql_real_escape_string instead.

The difference between mysql_real_escape_string and addslashes is:

Difference 1:

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

To fix this bug, try using the iconv function, convert the variable into a UTF-16, and then escape using addslashes.

This is one of the reasons that addslashes is not used for escape.

Difference 2:

Compared with addslashes, mysql_real_escape_string also escapes \ r, \ n, and \ x1a. It seems that these characters must be correctly told to MySQL, otherwise the query results will be incorrect.

This is another reason not to use addslashes for escape.

Addslashes V. S. mysql_real_escape_string

In GBK, 0xbf27 is not a valid multi-character, but 0xbf5c is. In a single-byte environment, 0xbf27 is regarded as 0xbf followed by 0x27 ('), and 0xbf5c is regarded as 0xbf followed by 0x5c (\).

A single quotation mark escaped with a backslash cannot effectively prevent SQL injection attacks against MySQL. If you use addslashes, I (attacker, the same below) are very lucky. I just need to inject something like 0xbf27, and then addslashes changes it to 0xbf5c27, a valid multi-byte character followed by a single quotation mark. 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 a dual-byte character.

In this demonstration, I will use the mysqli extension of MySQL 5.0 and PHP. If you want to try it, make sure you use GBK.

Create a table named users:
Copy codeThe Code is as follows:
Create table users (
Username VARCHAR (32) character set gbk,
Password VARCHAR (32) character set gbk,
Primary key (username)
);
The following code simulates the situation where only addslashes (or magic_quotes_gpc) is used to escape the queried data:
Copy codeThe 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 (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) {/* succeeded */} else {/* failed */}

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

To avoid this vulnerability, use mysql_real_escape_string, the Prepared statement (Prepared Statements, I .e. "parameterized Query"), or any mainstream database abstract class library.