php – mysql_real_escape_string的缺点？
|
我已经看到一些人在这里声明使用
mysql_real_escape_string连接查询不会保护您(完全)从SQL注入攻击.
但是,我还没有看到一个输入的例子说明mysql_real_escape_string不会保护你的攻击.大多数示例都忘记mysql_query被限制在一个查询中,并且使用mysql_real_escape_string不正确. 我唯一可以想到的例子如下： mysql_query('DELETE FROM users WHERE user_id = '.mysql_real_escape_string($input));
这不会保护您免受以下输入： 5 OR 1=1 我会看到这是错误的使用mysql_real_escape_string而不是一个缺点,它是专为字符串而不是数值.您应该转换为数字类型,或者如果要将输入视为字符串进行清理时,您应该在查询中执行相同操作,并在其周围引用引号. 任何人都可以提供一个可以绕过mysql_real_escape_string的输入示例,而不依赖于不正确的数值处理,或者忘记mysql_query只能执行一个查询？ 编辑：我对mysql_real_escape_string的限制感兴趣,而不是将其与替代方案进行比较,我意识到新项目有更好的选择,并没有争议.
mysql_real_escape_string或者一般的mysql_扩展的主要缺点是,比其他更现代化的API尤其是准备好的语句更难应用. mysql_real_escape_string应该在一种情况下使用：转义用作引号之间的SQL语句中的值的文本内容.例如.：
$value = mysql_real_escape_string($value,$link);
$sql = "... `foo` = '$value' ...";
^^^^^^
mysql_real_escape_string确保上述上下文中的$值不会弄乱SQL语法.它不工作,你可能在这里认为： $sql = "... `foo` = $value ..."; 或在这里： $sql = "... `$value` ..."; 或在这里： $sql = mysql_real_escape_string("... `foo` = '$value' ...");
如果应用于在SQL语句中引用的字符串以外的任何上下文中使用的值,则它将被错误地应用,并且可能会弄乱所得到的语法和/或允许某人提交可能启用SQL注入攻击的值. mysql_real_escape_string的用例很窄,但很少被正确理解. 使用mysql_real_escape_string进入热水的另一种方法是使用错误的方法设置数据库连接编码时.你应该做这个： mysql_set_charset('utf8',$link);
你也可以这样做： mysql_query("SET NAMES 'utf8'",$link);
问题是后者绕过了mysql_ API,它仍然认为你正在使用latin1(或其他东西)与数据库交谈.当使用mysql_real_escape_string时,它将假定错误的字符编码和转义字符串与数据库稍后会解释的方式不同.通过运行SET NAMES查询,您在mysql_ client API如何处理字符串以及数据库如何解释这些字符串之间创建了一个裂缝.这可以用于某些多字节串情况下的注入攻击. mysql_real_escape_string中没有基本的注入漏洞,我知道它是否正确应用.再次,主要的问题是错误地应用它是非常容易的,这会打开漏洞. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |