mysql_real_escape_string对于非常简单的数据库插入是否足够?
punde 发布于 2018-10-11 • 在 mysql • 最后更新 2018-10-11 22:59 • 26 浏览

示例代码:
$email = "" . $_POST['email']; $con = mysql_connect("localhost","user","pass") or die('Could not connect to database.'); mysql_select_db("face", $con); // Sanitization step $sanitemail = mysql_real_escape_string($email); // Is this safe? mysql_query("INSERT INTO landing_oct_2010 (email) VALUES ('$sanitemail');");我想知道,对于这个简单的任务,仅仅使用
mysql_real_escape_string
是否完全足以至少防止注入式SQL攻击,或者是否应该采取其他预防措施。
我在本示例中收集电子邮件地址的事实是偶然的。如果我知道我正在使用电子邮件地址,那么我只需输入一个正则表达式和一些DNS检查,并且我也会在验证中建立这些检查。但是,我想关注一下手头的一般问题:单一的卫生功能是否足够?
没有找到相关结果
已邀请:
5 个回复
dodit
赞同来自:
是的,总的来说。 但是必须记住一些重要条件:
mysql_set_charset()
函数。否则,如果使用多字节编码,而不是utf-8,则此功能无效。xid
赞同来自:
是的,这已经足够了。与
addslashes()
相比,mysql_real_escape_string()
知道哪些字符影响MySQL命令。此外,您可以在不使用stripslashes()
的情况下检索和使用数据库中的数据。lsint
赞同来自:
我也会使用trim去除空格
gqui
赞同来自:
是的,这就足够了。好吧,有点。 如果使用得当且一致,
mysql_real_escape_string
应足以防止SQL注入。该函数(与mysql_escape_string
不同)将连接的字符集考虑在内,因此只要您使用正确的字符集进行实际通信,它就可以适用于任何站点。 但是,在过去,转义例程中的bugs have existed,无论如何都可能导致SQL注入(在适当的条件下)。 更好的选择是使用MySQLi库进行参数化查询,因为这样可以完全避免转义。参数化查询基本上通过将数据与查询结构分离来工作,这反过来意味着不可能进行SQL注入。实现方面,数据库开发人员更难以引入允许SQL注入的错误,因为查询结构是单独给出的。adolor
赞同来自:
据我所知,有一些有用的东西: 代理人的地方0