mysql_real_escape_string() 是否完全防止 SQL 注入？
在 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
这是真的吗？ 如果是这样，如果您无法访问准备好的声明，您将如何保护您的网站免受这种情况的影响？
On http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-this , there is a section that claims you can bypass mysql_real_escape_string with certain Asian character encodings
Bypassing mysql_real_escape_string() with BIG5 or GBK
"injection string"
に関する追加情報：the above chars are Chinese Big5
Is this really true? And if so, how would you protect your website against this, if you had no access to prepared statements?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
根据 Stefan Esser 的说法，“使用
SET NAMES时，mysql_real_escape_string()[is] 不安全。”他的解释是，来自他的博客：
不过，他确实提到 UTF-8 是安全的。
According to Stefan Esser, "
mysql_real_escape_string()[is] not safe whenSET NAMESis used."His explanation, from his blog:
He does mention that UTF-8 is safe, though.
这是一个 MySQL 服务器错误，据报道早在 2006 年 5 月就已修复。
请参阅：
该错误已在 MySQL 4.1.20、5.0.22、5.1.11 中修复。
如果您使用 4.1.x、5.0.x 或 5.1.x，请确保您至少已升级到次要版本号。
作为解决方法，您还可以启用 SQL 模式
NO_BACKSLASH_ESCAPES禁用反斜杠作为引号转义字符。This is a MySQL server bug that was reportedly fixed way back in May 2006.
See:
The bug was reported fixed in MySQL 4.1.20, 5.0.22, 5.1.11.
If you use 4.1.x, 5.0.x, or 5.1.x, make sure you have upgraded at least to the minor revision numbers.
As a workaround, you can also enable the SQL mode
NO_BACKSLASH_ESCAPESwhich disables backslash as a quote-escape character.我很确定只有当您使用 SQL 更改 char 编码时它才不起作用。
I'm pretty sure it only doesn't work if you use SQL to change the char encoding.
正如其他人所证明的，
mysql_real_escape_string()在模糊的边缘情况下可以被绕过。 这是绕过转义逻辑的一种已知策略，但可能还有其他尚未发现的未知漏洞。准备好的语句在实际使用时而不是由 PDO 驱动程序模拟时，可证明是安全的（至少在 SQL 注入方面），因为它们解决了应用程序安全性的基本问题：它们将数据与对数据进行操作的指令。 它们以单独的数据包发送； 参数化值永远不会污染查询字符串。
都2015年了，别再逃避和串联了。 您仍然应该根据应用程序（和业务）逻辑验证您的输入，但只需使用准备好的语句。
As others have demonstrated,
mysql_real_escape_string()can be bypassed in obscure edge cases. That's one known strategy for bypassing the escaping logic, but there could be other unknown vulnerabilities that have not been discovered yet.The simple and effective way to prevent SQL injection in PHP is to use prepared statements where you can, and a very strict whitelist where you can't.
Prepared statements, when actually used and not emulated by the PDO driver, are provably secure (at least with regards to SQL injection), as they solve a fundamental problem with application security: they separate the data from the instructions that operate on the data. They're sent in separate packets; the parameterized values never have a chance to taint the query string.
It's 2015. Don't escape and concatenate anymore. You should still validate your inputs according to application (and business) logic, but just use prepared statements.