绕过 mysql_real_escape_string() 的 SQL 注入

考虑以下查询：

$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";

---

TL;DR mysql_real_escape_string() 在以下情况下将不提供任何保护（并且可能进一步破坏您的数据）： MySQL 的 NO_BACKSLASH_ESCAPES SQL 模式已启用（它可能是，除非您在每次连接时明确选择另一个 SQL 模式）；并且您的 SQL 字符串文字使用双引号 " 字符引用。这是作为错误 #72458 提交的，并已在 MySQL v5.7.6 中修复（请参阅下面标题为“The Saving Grace”的部分）。

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

为了向 @ircmaxell's excellent answer 致敬（真的，这应该是奉承而不是抄袭！），我将采用他的格式：

攻击

从演示开始...

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 表中的所有记录。解剖：

选择 SQL 模式 mysql_query('SET SQL_MODE="NO_BACKSLASH_ESCAPES"');如字符串文字中所述：有几种方法可以在字符串中包含引号字符：用“'”引用的字符串中的“'”可以写为“''”。用“"”引用的字符串中的“"”可以写成“""”。在引号字符前加上转义字符 (“\”)。用“"”引用的字符串中的“'”不需要特殊处理，也不需要加倍或转义。同样，用“'”引用的字符串中的“"”不需要特殊处理。如果服务器的 SQL 模式包含 NO_BACKSLASH_ESCAPES，则这些选项中的第三个——这是 mysql_real_escape_string() 采用的常用方法——不可用：必须使用前两个选项之一。请注意，第四个项目符号的效果是必须知道将用于引用文字的字符，以避免篡改数据。有效负载 " OR 1=1 -- 有效负载完全使用 " 字符启动此注入。没有特定的编码。没有特殊字符。没有奇怪的字节。 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, ulong length) { 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: /* 通过将撇号加倍来转义撇号 // [ deletia 839- 845 ] 描述 这通过将字符串包含的任何撇号加倍来转义字符串的内容。当 NO_BACKSLASH_ESCAPES SQL_MODE 在服务器上生效时使用此选项。 // [ deletia 852-858 ] */ size_t escape_quotes_for_mysql(CHARSET_INFO *charset_info, char *to, size_t to_length, const char *from, size_t length) { // [ deletia 865-892 ] if (*from == '\' ') { if (to + 2 > to_end) { 溢出= TRUE;休息; } *to++= '\''; *to++= '\'';因此，无论用于引用文字的实际字符如何，它都不会触及双引号 " 字符（并将所有单引号 ' 字符加倍）！在我们的例子中，$var 与提供给mysql_real_escape_string()——好像根本没有转义。查询 mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1'); 有点形式，呈现的查询是： SELECT * FROM test WHERE name = "" OR 1=1 --" LIMIT 1

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

坏的

mysql_set_charset() 无能为力，因为这与字符集无关； mysqli::real_escape_string() 也不能，因为这只是同一函数的不同包装。

问题（如果不是很明显的话）是对 mysql_real_escape_string() 无法知道使用哪个字符引用文字的调用，因为这留给开发人员稍后决定。因此，在 NO_BACKSLASH_ESCAPES 模式下，实际上没有办法，此函数可以安全地转义每个输入以用于任意引用（至少，在不需要加倍的字符加倍的情况下，这会影响你的数据）。

丑陋的

它变得更糟。 NO_BACKSLASH_ESCAPES 在野外可能并不罕见，因为它必须用于与标准 SQL 兼容（例如，参见 SQL-92 specification 的第 5.3 节，即 <quote symbol> ::= <quote><quote> 语法产生式并且缺乏赋予反斜杠）。此外，对于 ircmaxell 的帖子所描述的（早已修复的）bug，它的使用是明确的 recommended as a workaround。谁知道呢，一些 DBA 甚至可能将其配置为默认开启，以阻止使用不正确的转义方法（如 addslashes()）。

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

拯救恩典

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

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

在 PDO 中，它的等效函数 PDO::quote() 和它的预处理语句仿真器都调用 mysql_handle_quoter() — 这正是这样做的：它确保转义的文字用单引号引起来，因此您可以确定 PDO 始终免疫这个错误。

自 MySQL v5.7.6 起，此错误已得到修复。请参阅change log：

添加或更改的功能 不兼容的更改：已实现一个新的 C API 函数 mysql_real_escape_string_quote() 以替代 mysql_real_escape_string()，因为启用 NO_BACKSLASH_ESCAPES SQL 模式时后一个函数可能无法正确编码字符。在这种情况下，mysql_real_escape_string() 不能转义引号字符，除非将它们加倍，并且要正确执行此操作，它必须知道有关引用上下文的更多信息而不是可用的信息。 mysql_real_escape_string_quote() 需要一个额外的参数来指定引用上下文。有关使用详情，请参阅 mysql_real_escape_string_quote()。注意应修改应用程序以使用 mysql_real_escape_string_quote()，而不是 mysql_real_escape_string()，如果启用 NO_BACKSLASH_ESCAPES，现在会失败并产生 CR_INSECURE_API_ERR 错误。参考：另见错误 #19211994。

安全示例

结合ircmaxell解释的bug，下面的例子是完全安全的（假设一个是使用晚于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 准备好的语句是安全的。

包起来

因此，如果您：

使用本机准备好的语句

或者

使用 MySQL v5.7.6 或更高版本

或者

除了采用 ircmaxell 总结中的解决方案之一，至少使用以下之一： PDO；单引号字符串文字；或不包含 NO_BACKSLASH_ESCAPES 的显式设置的 SQL 模式

PDO;

单引号字符串文字；或者

不包含 NO_BACKSLASH_ESCAPES 的显式设置的 SQL 模式

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

---

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

---