mysql_real_escape_string（）是否损坏？

Question

有些人认为这样做mysql_real_escape_string()存在一些缺陷，即使正确使用也无法保护您的查询。带一些化石的物品作为证明。因此，问题是：mysql [i] _real escape_string（）完全不可接受吗？还是仍然可以使用此功能来创建自己的预备语句？请提供校对码。

Answer 1

从MySQL的C API函数mysql_real_escape_string描述：

如果需要更改连接的字符集，则应使用mysql_set_character_set()函数而不是执行SET NAMES（或SET CHARACTER SET）语句。mysql_set_character_set()的工作方式类似，SET NAMES但也会影响所使用的字符集mysql_real_escape_string()，而SET NAMES不会。

因此，请勿使用SET NAMES/，SET CHARACTER SET而应使用PHPmysql_set_charset来更改编码，因为它与MySQL的编码相对应mysql_set_character_set（请参见/ext/mysql/php_mysql.c的源代码）。

Answer 2

但是，即使使用旧代码和旧服务器版本，也只有在数据库连接的字符集从单字节（如Latin-1）更改为允许值0x5c（ASCII单引号）的多字节时，才能触发此漏洞。 ）放在多字节字符的第二个字节或更高字节中。

具体来说，与GBK和SJIS之类的较旧的亚洲编码不同，UTF-8不允许这样做。因此，如果您的应用程序不更改连接字符集，或仅将其更改为UTF-8或诸如Latin-n的单字节字符集，则可以免受这种攻击。

但是最佳实践仍然是运行最新的服务器版本，使用正确的界面来更改字符集，并使用准备好的查询，这样您就不会忘记转义。

Answer 3

在注释中有一个指向mySQL 5.0.22（2006年5月24日）中的错误修正的链接，此问题已得到解决。