The difference between PHP function addslashes and mysql_real_escape_string _php instance

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

The difference between mysql_real_escape_string and addslashes is:

Difference One:

Addslashes does not know anything about the MySQL connection's character set. If you pass a string of code other than the byte code to the MySQL connection you are using, it will be nice to escape all the characters ', ', \ and \x00 bytes. If you are using other characters that are different from 8-bit and UTF-8, the values of these bytes may not all represent characters ', ', \ and \x00. As a result, MySQL receives these characters and an error occurs.

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

This is one of the reasons to escape 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 you will get the wrong query results.

This is another reason to escape without using addslashes.

Addslashes V.s. mysql_real_escape_string

In GBK, 0xbf27 is not a legitimate character of multiple characters, but 0xbf5c is. In a single-byte environment, 0xbf27 is considered 0xbf followed by 0x27 ('), while 0xbf5c is considered 0XBF followed by 0x5c (\).

A single quote that is escaped with a backslash is not effective in preventing SQL injection attacks against MySQL. If you use Addslashes, then I'm lucky (the attacker, the same below). I just inject something like 0xbf27 and then addslashes it to 0xbf5c27, a valid multi-byte character followed by a single quote. In other words, I can ignore your escape and successfully inject a single quote. This is because 0XBF5C is treated as a single-byte character, not a double byte.

In this demo, I will use the MySQL 5.0 and PHP mysqli extensions. If you want to try, make sure you use GBK.

Create a table named users:

Copy Code code as follows:

CREATE TABLE Users (
Username VARCHAR () CHARACTER SET GBK,
Password VARCHAR () CHARACTER SET GBK,
PRIMARY KEY (username)
);

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

Copy Code code as follows:

<?php
$mysql = Array ();
$db = Mysqli_init ();
$db->real_connect (' localhost ', ' lorui ', ' lorui.com ', ' lorui_db ');
/* SQL Injection Sample * *
$_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) {/* Success/else {/* failure/}

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

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