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

2020/12/31 17:41 · php ·  · 0评论

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

这是真的吗?如果是这样,如果您无法访问准备好的陈述,那么您将如何保护您的网站呢?

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

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

我敢肯定,只有当您使用SQL更改char编码时,它才行不通。

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

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

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

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

本文地址:http://php.askforanswer.com/mysql_real_escape_stringshifouwanquankeyifangzhisqlzhuru.html
文章标签: ,   ,  
版权声明:本文为原创文章,版权归 admin 所有,欢迎分享本文,转载请保留出处!

文件下载

老薛主机终身7折优惠码boke112

上一篇:
下一篇:

评论已关闭!