加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > PHP教程 > 正文

php – 为什么mysql_real_escape_string()不应该避免任何SQL注入

发布时间:2020-12-13 13:30:53 所属栏目:PHP教程 来源:网络整理
导读:我听过有人说(关于C#/ SQL Server,但也与 PHP / MySql有关):不要手动转义字符串 – 而是使用存储过程. 好的,我可以接受这个建议,但为什么呢?很多人说(包括在SO上)mysql_real_escape_string()就足够了,mysql_real_escape_string()是好的,mysql_real_escape_
我听过有人说(关于C#/ SQL Server,但也与 PHP / MySql有关):不要手动转义字符串 – 而是使用存储过程.

好的,我可以接受这个建议,但为什么呢?很多人说(包括在SO上)mysql_real_escape_string()就足够了,mysql_real_escape_string()是好的,mysql_real_escape_string()是第一种保护方式.

为什么?有没有mysql_real_escape_string()失败的情况?至少一个……我不需要很多:)

当mysql_real_escape_string失败时:
$sql = "SELECT * FROM users WHERE id=" + mysql_real_escape_string($_GET['id']);

如果$_GET [‘user_id’]设置为1或1 = 1,则没有特殊字符且未过滤.

结果:返回所有行.

它变得更糟.怎么样…如果$_GET [‘user_id’]设置为1或is_admin = 1怎么办?

该功能仅用于单引号内部时使用.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读