mysql_real_escape_string 失败且需要准备语句的具体示例

Question

我一直在使用 mysql_real_escape_string 和其他函数来清理我的输入，并且最近读到准备好的语句是真正安全的唯一方法。然而，我不愿意使用它们有两个原因：我不想重写代码，并且我了解到使用它们会对性能产生影响（在此应用程序中广泛使用查询）。

因此，我正在寻找一个最近的具体示例，说明 mysql_real_escape_string 在查询中失败，解决方案是使用准备好的语句（即，无法进一步清理输入并保证其安全）。

我问这个问题是因为我能找到的唯一符合上述标准的例子是前一段时间的，并且已经在更新版本的 php 中进行了修补。

Answer 1

从该函数的 PHP 文档 (http://php.net/mysql_real_escape_string) 中，它显示“mysql_real_escape_string( ) 调用 MySQL 的库函数 mysql_real_escape_string，该函数在以下字符前面添加反斜杠：\x00、\n、\r、\、'、 “和\x1a。”
因此，它的用处取决于上下文。因此，举例来说，如果您遇到以下情况：

$user_input = mysql_real_escape_string($_GET['user_input']);
$query = "SELECT * FROM `users` WHERE `id` = $user_input";
$result = mysql_query($query);

嗯，那将是非常愚蠢的。因为如果字符串是 0 或 9=9，那么它不包含函数转义的任何字符。然而，当注入 $query 文字时，它会产生：

$query = "SELECT * FROM `users` WHERE `id` = 0 or 9=9";

这将返回 users 表中的所有行......这可能不是程序员的意图。

因此，总而言之，如果用户输入由 mysql_real_escape_string() 处理，但在整数或其他数字数据类型的上下文中使用，那么它将无法提供足够的保护。

使用准备好的语句，您可以确保每个值不仅被转义，而且被验证为正确的数据类型。

在上面的示例中，处理该问题的最安全方法是使用 intval() 函数而不是 mysql_real_escape_string() 函数。

希望这是有道理的。

Answer 2

mysql_real_escape_string() 的全部目的是 100% 保证用它转义的数据中不会有 SQL 注入。它远远优于 addslashes()，因为它考虑了当前连接的字符编码。

如果该功能在实际实现中不存在严重错误，那么可以安全使用。

人们不希望您使用它的原因是您可能忘记在某个地方或另一个地方，从而打开安全漏洞。准备好的语句更难搞砸，但是如果正确转义数据，构建自己的 SQL 并没有什么根本性的错误。

编辑：

请注意在建立连接后可能会更改连接的字符集，从而导致与 mysql_real_escape_string 不同步。我还没有确认情况仍然如此。

另请注意，mysql_real_escape_string() 必须是在将数据与 SQL 连接之前对数据执行的最后一个操作。

另外，不要忘记引号！例如。 AND name = "' .mysql_real_escape_string($name) . '"

Answer 3

mysql_real_escape_string 100% 可靠。这就是您随后对转义数据所做的操作失败的原因。

例如，

$safe = mysql_real_escape_string('some nasty injection-riddled data here');
$unsafe = htmlspecialchars($safe);

m_r_e_s 将完美地完成其工作，然后您可能会通过之后再次摆弄字符串来撤消所有操作。

m_r_e_s 应该是在 SQL 查询中使用字符串之前对字符串执行的最后一个操作。