mysql_real_escape_string（）是否完全可以防止SQL注入？

Question

在http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-this上，有一节声称您可以使用某些亚洲字符编码绕过mysql_real_escape_string用BIG5或GBK绕过mysql_real_escape_string（）“注入线”に关する追加情报：以上字符是中国Big5这是真的吗？如果是的话，如果您无法访问准备好的陈述，那么如何保护您的网站呢？

Answer 1

根据Stefan Esser的说法，“ mysql_real_escape_string()[ SET NAMES使用时不安全] 。”

来自他的博客的解释：

SET NAMES通常用于将编码从默认设置切换到应用程序需要的设置。这是mysql_real_escape_string不知道的方式完成的。这意味着，如果您切换到允许反斜杠作为2nd 3rd 4th…字节的多字节编码，则会遇到麻烦，因为mysql_real_escape_string无法正确转义。UTF-8是安全的…

更改编码的安全方法是mysql_set_charset，但这仅在新的PHP版本中可用

他确实提到UTF-8是安全的。

Answer 2

这是一个MySQL服务器错误，据报道早在2006年5月就已修复。

看到：

• MySQL错误＃8303：具有包含\的多字节字符的字符串文字被错误地词汇化

• MySQL Bug＃8317：查询中的字符集介绍程序无法覆盖连接字符集

• MySQL错误＃8378：字符串错误地用客户端字符集'gbk'逸出

• MySQL的5.1.11 更新日志。

据报告该错误已在MySQL 4.1.20、5.0.22、5.1.11中修复。

如果使用4.1.x，5.0.x或5.1.x，请确保至少已升级到次要修订号。

解决方法是，您还可以启用SQL模式NO_BACKSLASH_ESCAPES，该模式禁用反斜杠作为引号转义字符。

Answer 3

正如其他人所证明的，mysql_real_escape_string()在晦涩的边缘情况下可以绕开。这是绕过转义逻辑的一种已知策略，但是可能还有其他未知漏洞尚未发现。

防止PHP中的SQL注入的一种简单有效的方法是在可能的地方使用准备好的语句，在不能的地方使用非常严格的白名单。

经证明的预处理语句在实际使用且不受PDO驱动程序仿真时，被证明是安全的（至少在SQL注入方面），因为它们解决了应用程序安全性的根本问题：它们将数据与对数据进行操作的指令分开。它们以单独的数据包发送；参数化的值永远不会有机会污染查询字符串。

是2015年。不要逃脱和连接了。您仍然应该根据应用程序（和业务）逻辑来验证输入，但是只使用准备好的语句。