绕过 mysql_real_escape_string() 的 SQL 注入

Question

即使使用 mysql_real_escape_string() 函数，是否也存在 SQL 注入的可能性？

考虑这个示例情况。 SQL 是这样在 PHP 中构建的：

$login = mysql_real_escape_string(GetFromPost('login'));
$password = mysql_real_escape_string(GetFromPost('password'));

$sql = "SELECT * FROM table WHERE login='$login' AND password='$password'";

我听到很多人对我说，即使使用 mysql_real_escape_string() 函数，这样的代码仍然很危险并且可能被黑客攻击。但我想不出任何可能的利用？

像这样的经典注射：

aaa' OR 1=1 --

不起作用。

你知道有什么可能的注入可以通过上面的 PHP 代码吗？

Answer 1

简短的回答是是的，是的，有一种方法可以绕过mysql_real_escape_string()。
#对于非常模糊的边缘情况！！！

长答案并不那么容易。它基于此处演示的攻击。

攻击

那么，让我们首先展示攻击......

mysql_query('SET NAMES gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

在某些情况下，这将返回超过 1 行。让我们剖析一下这里发生的事情：

1. 选择字符集

   mysql_query('设置名称 gbk');
   

   要使此攻击发挥作用，我们需要服务器期望连接上的编码将 ' 编码为 ASCII，即 0x27 和 得到一些最终字节为 ASCII \ 的字符，即 0x5c。事实证明，MySQL 5.6 默认支持 5 种这样的编码：big5、cp932、gb2312、gbk和<代码>sjis。我们将在这里选择gbk。

   现在，请注意此处 SET NAMES 的使用，这一点非常重要。这将字符集设置在服务器上。如果我们使用对 C API 函数 mysql_set_charset() 的调用，那就没问题（自 2006 年以来的 MySQL 版本）。但稍后会详细说明原因...

2. 有效负载

   我们将用于此注入的有效负载以字节序列 0xbf27 开头。在 gbk 中，这是一个无效的多字节字符；在 latin1 中，它是字符串 ¿'。请注意，在 latin1 和 gbk 中，0x27 本身就是一个文字 '性格。

   我们选择此有效负载是因为，如果我们对其调用 addslashes()，我们将插入一个 ASCII \ 即 0x5c，在 ' 字符之前。因此，我们最终会得到 0xbf5c27，它在 gbk 中是一个两个字符序列：0xbf5c 后跟 0x27 。或者换句话说，一个有效字符后跟一个未转义的'。但我们没有使用 addslashes()。那么继续下一步...

3. mysql_real_escape_string()

   对 mysql_real_escape_string() 的 C API 调用与 addslashes() 的不同之处在于它知道连接字符集。因此它可以对服务器期望的字符集正确执行转义。然而，到目前为止，客户端认为我们仍在使用 latin1 进行连接，因为我们从未告诉过它。我们确实告诉服务器我们正在使用gbk，但客户端仍然认为它是latin1。

   因此，对 mysql_real_escape_string() 的调用会插入反斜杠，并且我们的“转义”内容中有一个自由悬挂的 ' 字符！事实上，如果我们查看 gbk 字符集中的 $var，我们会看到：

   缞' OR 1=1 /*

   这是到底是什么攻击需要。

4. 查询

   这部分只是形式，但这是呈现的查询：

   SELECT * FROM test WHERE name = '缞' OR 1=1 /*' LIMIT 1
   

恭喜，您刚刚使用 mysql_real_escape_string() 成功攻击了一个程序...

坏处

情况变得更糟。 PDO 默认使用 MySQL模拟准备好的语句。这意味着在客户端，它基本上通过 mysql_real_escape_string() （在 C 库中）执行 sprintf，这意味着以下操作将导致成功注入：

$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

现在，值得注意的是，您可以通过禁用模拟准备语句来防止这种情况：

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

这通常会产生真正的准备语句（即数据在与查询不同的数据包中发送）。但是，请注意，PDO 会默默后备 来模拟 MySQL 本身无法准备的语句：它可以的语句是 在手册中列出，但要注意选择适当的服务器版本）。

丑陋的是

我在一开始就说过，如果我们使用mysql_set_charset('gbk')而不是SET NAMES gbk，我们就可以避免这一切。如果您使用的是 2006 年以来的 MySQL 版本，则确实如此。

如果您使用的是早期 MySQL 版本，则 mysql_real_escape_string() 中的“noreferrer">bug 意味着无效的多字节字符（例如我们的有效负载中的字符）出于转义目的被视为单个字节，即使客户端已正确处理得知连接编码，因此此攻击仍然会成功。该错误已在 MySQL 4.1.20，5.0.22 和 5.1.11。

但最糟糕的是 PDO 直到 5.3.6 才公开 mysql_set_charset() 的 C API，因此在之前的版本中它不能针对每个可能的命令防止这种攻击！
它现在公开为 DSN 参数。

正如

我们在一开始所说的，要使这种攻击起作用，数据库连接必须使用易受攻击的字符集进行编码。 utf8mb4 不是容易受到攻击，但可以支持每个 Unicode 字符：因此您可以选择使用它，但它从 MySQL 5.5.3 起才可用。另一种选择是 utf8，也不易受攻击，并且可以支持整个 Unicode 基本多语言飞机。

或者，您可以启用 NO_BACKSLASH_ESCAPES SQL 模式，它（除其他外）改变 mysql_real_escape_string() 的操作。启用此模式后，0x27 将被替换为 0x2727 而不是 0x5c27，因此转义进程无法创建有效的以前不存在的任何易受攻击的编码中的字符（即 0xbf27 仍然是 0xbf27 等），因此服务器仍会拒绝该字符串视为无效。但是，请参阅 @eggyal 的回答，了解使用此 SQL 模式可能出现的不同漏洞。

安全示例

以下示例是安全的：

mysql_query('SET NAMES utf8');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

因为服务器期望 utf8...

mysql_set_charset('gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

因为我们已经正确设置了字符集，以便客户端和服务器匹配。

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

因为我们已经关闭了模拟准备语句。

$pdo = new PDO('mysql:host=localhost;dbname=testdb;charset=gbk', $user, $password);
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

因为我们已经正确设置了字符集。

$mysqli->query('SET NAMES gbk');
$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "\xbf\x27 OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();

因为 MySQLi 始终执行真正的准备好的语句。

总结

如果您：

• 使用现代版本的 MySQL（5.1 晚期、所有 5.5、5.6 等）AND mysql_set_charset() / $mysqli->set_charset( ) / PDO 的 DSN 字符集参数（在 PHP ≥ 5.3.6 中）

OR

• 不要使用易受攻击的字符集进行连接编码（您仅使用 utf8 / latin1 / ascii / 等）

您 100% 安全。

否则，即使您使用 mysql_real_escape_string()，您也很容易受到攻击...

Answer 2

考虑以下查询：

$iId = mysql_real_escape_string("1 OR 1=1");    
$sSql = "SELECT * FROM table WHERE id = $iId";

mysql_real_escape_string() 不会保护您免受这种情况的影响。
事实上，您在查询中的变量周围使用单引号 (' ') 可以防止出现这种情况。以下也是一个选项：

$iId = (int)"1 OR 1=1";
$sSql = "SELECT * FROM table WHERE id = $iId";

Answer 3

TL;DR

mysql_real_escape_string() 将不提供任何保护（并且可能进一步破坏您的数据），如果：

• MySQL 的 NO_BACKSLASH_ESCAPES SQL 模式已启用（可能，除非您在每次连接时明确选择另一种 SQL 模式）；和

• 您的 SQL 字符串文字使用双引号 " 字符引用。

这已被归档为 bug #72458 并已在 MySQL v5 中修复.7.6（参见下面标题为“拯救恩典”的部分）。

这是另一个（也许更少？）晦涩的边缘案例！

为了向 @ircmaxell 的出色答案致敬（真的，这应该是奉承而不是抄袭！），我将采用他的格式：

攻击

从演示开始...

mysql_query('SET SQL_MODE="NO_BACKSLASH_ESCAPES"'); // could already be set
$var = mysql_real_escape_string('" OR 1=1 -- ');
mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

这将返回 test 表中的所有记录。剖析：

1. 选择 SQL 模式

   mysql_query('SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
   

   如字符串文字下所述：

   <块引用>

   有多种方法可以在字符串中包含引号字符：

   • 用“'”引用的字符串内的“'”可以写为“''”。

   • 用“””引用的字符串内的“””可以写为“”“”。

   • 在引号字符前添加转义字符（“\”）。

   • 用“””引用的字符串中的“'”不需要特殊处理，不需要加倍或转义。同样，“用“'”引用的字符串内的“”不需要特殊处理。

   如果服务器的 SQL 模式包括 NO_BACKSLASH_ESCAPES ，那么这些选项中的第三个（这是 mysql_real_escape_string() 采用的常用方法）不可用：必须使用前两个选项之一。请注意，第四个项目符号的效果是，必须知道将用于引用文字的字符，以避免修改数据。

2. 有效负载

   " 或 1=1 -- 
   

   有效负载完全使用 " 字符启动此注入。没有特定的编码。没有特殊字符。没有奇怪的字节。

3. mysql_real_escape_string()

   $var = mysql_real_escape_string('" OR 1=1 -- ');
   

   幸运的是，mysql_real_escape_string() 确实检查 SQL 模式并相应地调整其行为。请参阅 libmysql.c：

   ulong STDCALL
   mysql_real_escape_string(MYSQL *mysql, char *to,const char *from,
                超长长度）
   {
     if (mysql->server_status & SERVER_STATUS_NO_BACKSLASH_ESCAPES)
       return escape_quotes_for_mysql(mysql->charset, to, 0, from, length);
     return escape_string_for_mysql(mysql->charset, to, 0, from, length);
   }
   

   因此，如果使用 NO_BACKSLASH_ESCAPES SQL 模式，则会调用不同的底层函数 escape_quotes_for_mysql()。如上所述，这样的函数需要知道将使用哪个字符来引用文字，以便重复它，而不会导致其他引用字符被文字重复。

   但是，此函数任意假设使用单引号'字符来引用字符串。请参阅 charset.c：

   <代码>/*
     通过将撇号加倍来转义撇号
   
   // [删除839-845]
   
     描述
       这通过将任何撇号加倍来转义字符串的内容
       它包含。当 NO_BACKSLASH_ESCAPES SQL_MODE 处于
       对服务器的影响。
   
   // [删除852-858]
   */
   
   size_t escape_quotes_for_mysql(CHARSET_INFO *charset_info,
                                  char *to，size_t to_length，
                                  const char *from, size_t 长度)
   {
   // [删除865-892]
   
       if (*from == '\'')
       {
         if (to + 2 > to_end)
         {
           溢出=真；
           休息;
         }
         *到++='\''；
         *到++='\''；
       }
   

   因此，无论用于引用的实际字符如何，它都会保持双引号 " 字符不变（并将所有单引号 ' 字符加倍）在我们的例子中，$var 与提供给 mysql_real_escape_string() 的参数完全相同 - 就好像没有发生转义< em>完全没有。

4. 查询

   。

   mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');
   

   有点正式，呈现的查询是：

   SELECT * FROM test WHERE name = "" OR 1=1 -- " LIMIT 1
   

正如我博学的朋友所说：恭喜，您刚刚使用mysql_real_escape_string()<成功攻击了一个程序/code>...

不好的

mysql_set_charset()< /code> 没有帮助，因为这与字符集无关；也不能 mysqli::real_escape_string() ，因为这只是同一函数的不同包装。

问题（如果还不是很明显的话）是对 mysql_real_escape_string() 的调用无法知道将用哪个字符引用文字，因为这由开发人员决定稍后。因此，在 NO_BACKSLASH_ESCAPES 模式下，该函数实际上不可能能够安全地转义每个输入以用于任意引用（至少，不加倍不需要的字符）加倍并因此修改你的数据）。

丑陋的

事情变得更糟。 NO_BACKSLASH_ESCAPES 在野外可能并不那么罕见，因为它需要与标准 SQL 兼容（例如，请参阅 SQL-92 规范，即 ::= 语法产生并且反斜杠没有任何特殊含义）。此外，它的使用被明确推荐作为ircmaxell 的帖子描述的（早已修复）bug 的解决方法 。谁知道呢，一些 DBA 甚至可能将其配置为默认打开，以阻止使用不正确的转义方法，例如 addslashes()。

另外，新连接的 SQL 模式由服务器根据其配置进行设置（SUPER 用户可以随时更改）；因此，为了确定服务器的行为，您必须在连接后始终明确指定您所需的模式。

丑陋

只要您始终显式将 SQL 模式设置为不包含 NO_BACKSLASH_ESCAPES，或者使用单引号字符引用 MySQL 字符串文字，这个错误就不会变得 head：分别不会使用escape_quotes_for_mysql()，或者它关于哪些引号字符需要重复的假设是正确的。

因此，我建议任何使用 NO_BACKSLASH_ESCAPES 的人也启用 ANSI_QUOTES 模式，因为它将强制习惯使用单引号字符串文字。请注意，如果碰巧使用双引号文字，这并不能阻止 SQL 注入，它只是降低了发生这种情况的可能性（因为正常的非恶意查询会失败）。

在 PDO 中，其等效函数 PDO::quote() 及其准备好的语句模拟器调用 mysql_handle_quoter() — 正是这样做的：它确保转义文字用单引号引起来，因此您可以确定 PDO 始终不受此错误的影响。

从 MySQL v5.7.6 开始，此错误已得到修复。请参阅更改日志：

添加或更改的功能

• 不兼容的更改：新的 C API 函数，mysql_real_escape_string_quote() 已作为 mysql_real_escape_string() 因为后一个函数可以当 NO_BACKSLASH_ESCAPES SQL 模式已启用。在这种情况下， mysql_real_escape_string()< /code> 无法转义引号字符，除非将它们加倍，并且要正确执行此操作，它必须了解有关引用上下文的更多信息。 mysql_real_escape_string_quote() 需要一个额外的参数来指定引用上下文。有关使用详细信息，请参阅 mysql_real_escape_string_quote()< /a>.

  <块引用>

  注意事项

  应修改应用程序以使用 mysql_real_escape_string_quote()，而不是mysql_real_escape_string()，现在失败并生成 CR_INSECURE_API_ERR 如果NO_BACKSLASH_ESCAPES 已启用。

  参考文献：另请参阅错误#19211994。







安全示例

结合 ircmaxell 解释的错误，以下示例是完全安全的（假设使用 4.1.20、5.0.22、5.1.11 之后的 MySQL；或者不使用 GBK/Big5 连接编码）：

mysql_set_charset($charset);
mysql_query("SET SQL_MODE=''");
$var = mysql_real_escape_string('" OR 1=1 /*');
mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

...因为我们明确选择了不包含 NO_BACKSLASH_ESCAPES 的 SQL 模式。

mysql_set_charset($charset);
$var = mysql_real_escape_string("' OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

...因为我们用单引号引用字符串文字。

$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(["' OR 1=1 /*"]);

...因为 PDO 准备好的语句不受此漏洞的影响（ircmaxell 也是如此，前提是您使用 PHP≥5.3.6 并且已在 DSN 中正确设置字符集；或者准备好的语句模拟已被禁用） 。

$var  = $pdo->quote("' OR 1=1 /*");
$stmt = $pdo->query("SELECT * FROM test WHERE name = $var LIMIT 1");

...因为 PDO 的 quote() 函数不仅转义文字，而且还引用它（以单引号 ' 字符）；请注意，在这种情况下，为了避免 ircmaxell 的错误，您必须使用 PHP≥5.3.6 并且已在 DSN 中正确设置字符集。

$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "' OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();

...因为 MySQLi 准备好的语句是安全的。

总结

因此，如果您：

• 使用本机准备好的语句

OR

• 使用MySQL v5.7.6或更高版本

OR

• 此外使用以下之一ircmaxell 总结中的解决方案，至少使用以下之一：

  • PDO；
  • 单引号字符串文字；或
  • 显式设置的 SQL 模式，不包含 NO_BACKSLASH_ESCAPES

...那么您应该是完全安全的（字符串转义范围之外的漏洞除外）。

Answer 4

嗯，除了 % 通配符之外，没有什么可以真正通过它。如果您使用 LIKE 语句，则可能会很危险，因为如果您不过滤掉该语句，攻击者可能只将 % 作为登录名，并且只能暴力破解以下密码您的任何用户。
人们经常建议使用准备好的语句来使其 100% 安全，因为数据不会以这种方式干扰查询本身。
但对于这样简单的查询，执行类似 $login = preg_replace('/[^a-zA-Z0-9_]/', '', $login); 的操作可能会更有效