Is mysql_real_escape_string () broken?

Question

Some people believe that mysql_real_escape_string() has some drawbacks and cannot protect your request even when used correctly.
As evidence, some fossil articles can be cited.

So the question is: mysql [i] _real escape_string () is completely unacceptable?
Or is it possible to use this function to create your own prepared statements?

With verification code, please.

Answer 1

From MySQL mysql API function mysql_real_escape_string :

If you need to change the connection character set, you should use the mysql_set_character_set() function instead of doing SET NAMES (or SET CHARACTER SET ). mysql_set_character_set() works like SET NAMES , but also affects the character set used by mysql_real_escape_string() , which SET NAMES does not work.

So do not use SET NAMES / SET CHARACTER SET , but PHPs mysql_set_charset to change the encoding, as this is the equivalent of MySQLs mysql_set_character_set (see source code / ext / mysql / php_mysql.c ).

Answer 2

However, even with outdated code and older versions of the server, this vulnerability can only be launched if the character set of the database connection is changed from single-byte, such as Latin-1, to multi-byte, which allows using the value 0x5c (ASCII) in the second or later byte of a multibyte character.

In particular, UTF-8 does not allow this, unlike older Asian encodings such as GBK and SJIS. Therefore, if your application does not change the character set of the connection or changes it only to UTF-8 or single-byte, such as Latin-n, you can be safe from this exploit.

But it’s best to use the latest version of the server, use the right interface for changing character sets, and use prepared queries so you don’t forget to avoid things.

Answer 3

In the comments there is a link to a fix in mySQL 5.0.22 (May 24, 2006) , where it was considered.