mysql_real_escape_string的缺点？

Question

我在这里看到一些人说使用连接查询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而不是将它与替代品进行比较,我意识到新项目有更好的选择,我并不反对.

Answer 1

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确保$value在上面的上下文中不会弄乱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_客户端API如何处理字符串以及数据库将如何解释这些字符串之间的裂痕.这可以用于某些多字节字符串情况下的注入攻击.

没有基本的注入漏洞mysql_real_escape_string,我知道它是否正确应用.但是,主要的问题是,错误地应用它是非常容易的,这会打开漏洞.