Some people believe that
mysql_real_escape_string() has some flaws and cannot protect your query even when properly used.
Bringing some fossilized articles as a proof.
So, the question is: is mysql[i]_real escape_string() totally unacceptable?
Or is it’s still possible to use this function to create your own kind of prepared statements?
With proofcode, please.
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
If you need to change the character set of the connection, you should use the
mysql_set_character_set()function rather than executing a
SET CHARACTER SET) statement.
SET NAMESbut also affects the character set used by
SET NAMESdoes not.
However, even with legacy code and old server versions, the vulnerability can only be triggered if the character set of the database connection is changed from a single-byte one like Latin-1 to a multibyte one that allows the value 0x5c (ASCII single quote) in the second or later byte of a multibyte character.
Specifically, UTF-8 does not allow that, unlike older Asian encodings like GBK and SJIS. So if your application does not change the connection character set, or changes it only to UTF-8 or single-byte ones like Latin-n, you’re safe from this exploit.
But best practice is still to run the newest server version, use the correct interface to change character sets, and use prepared queries so you don’t forget to escape stuff.
In the comments there is a link to a bugfix in mySQL 5.0.22 (24 May 2006), where this has been addressed.