The difference between PHP functions Addslashes () and mysql_real_escape_string (), SQL injection attack analysis

First: Do not use mysql_escape_string (), which has been deprecated, 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 for escaping without using addslashes ().

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:

CREATE TABLE Users (username varchar (+) CHARACTER set Gbk,password varchar (+) CHARACTER set Gbk,primary KEY (username));

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

<?phpheader (' content-type:text/html; Charset=gbk '); $mysql = Array (); $db = Mysqli_init (); $db->real_connect (' LocalHost ', ' root ', ' root ', ' go-study ');/* 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 userswhere username = ' {$mysql [' username ']} ' and Password = ' {$mysql [' Password ']} ', Write2 ($sql); $result = $db->query ($sql); if ($result->num_rows) {/* success */} 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 the statement (Prepared statements, or "parameterized query") or any of the mainstream database abstraction class libraries.

The difference between PHP functions Addslashes () and mysql_real_escape_string (), SQL injection attack analysis