为了账号安全,请及时绑定邮箱和手机立即绑定

mysql_real_escape_string()是否完全可以防止SQL注入?

mysql_real_escape_string()是否完全可以防止SQL注入?

冉冉说 2019-12-26 10:56:00
在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这是真的吗?如果是的话,如果您无法访问准备好的陈述,那么如何保护您的网站呢?
查看完整描述

3 回答

?
杨魅力

TA贡献1811条经验 获得超5个赞

根据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是安全的。


查看完整回答
反对 回复 2019-12-26
?
慕标琳琳

TA贡献1830条经验 获得超9个赞

这是一个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,该模式禁用反斜杠作为引号转义字符。


查看完整回答
反对 回复 2019-12-26
?
青春有我

TA贡献1784条经验 获得超8个赞

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

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

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

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


查看完整回答
反对 回复 2019-12-26
  • 3 回答
  • 0 关注
  • 1030 浏览
慕课专栏
更多

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信