Mysql 使用两个单引号转义单引号时的SQL注入

当单引号被两个单引号转义时，有没有办法执行SQL注入？我知道MySQL服务器正在使用这种特定的技术来防止攻击。我正试图以特定用户身份登录，但我尝试的所有常用密码注入都没有成功（即“或“1”=“1”或“1=1”，等等）。

如果输入接受unicode并在数据库中隐式转换为ascii（听起来并不罕见），则攻击者可以简单地替换“或”（0x02BB或0x02BC）代替单勾号来绕过转义机制，隐式转换将这些字符映射为单勾号（至少在SQL Server中是这样）

否，以及是

如果所提供的值通过前面的单引号和附加的单引号进行“转义”，则无法将包含在单引号中的文字值的不安全值“断开”

也就是说，假设您的语句保证字符串文字被括在引号中，作为“静态”SQL文本的一部分

perl-ish/php-ish示例

$sql = "...  WHERE t.foo = '" . $safe_value . "' ... ";
                           ^                   ^

我在这里强调，包含文字的单引号是SQL文本的一部分。如果

$safe\u value

已通过在“safe”值中的每个单引号前面加上另一个单引号“safe”来“转义”

只要转义处理得当，我们就可以保证在转义过程中运行可能不安全的值，然后在数据值中包含单引号不是用SQL文本“断开”文本的可行方法

这是答案的“不”部分

答案的“是”部分

最大的问题之一是，假设潜在不安全的字符串是“安全的”，并且没有转义（例如，假设从数据库表中提取的值是“安全的”，并且在将它们包含在SQL文本中之前没有转义），确保在任何地方都执行此操作，并且没有在任何地方出错

此外，单引号技巧不是SQL注入的唯一途径。代码仍然可能容易受到攻击

首先，如果我们对语句的其他部分不小心，比如包含字符串文字的单引号。或者，例如，如果代码在提交到数据库之前通过其他函数运行

$sql

：

$sql = some_other_function($sql);

从

some\u other\u函数

返回可能会返回事实上易受攻击的SQL文本。（作为一个荒谬的例子，

some\u other\u函数

可能会将所有出现的两个连续单引号替换为一个单引号。DOH！）

此外，由于可能的unicode字符数量巨大，如果我们进行字符集转换，也有可能某些unicode字符会被映射到一个单引号字符。我没有任何具体的例子，但是在过多的多字节编码中，在某个地方，有s某个unicode字符将在某个目标中转换为单个引号

对于源中未映射的字符，目标中有一个默认字符，通常是问号（或黑色菱形中的白色问号）。如果目标中的默认字符（对于源中未映射的字符）是单引号，这将是一个巨大的问题

---

一句话：通过用两个单引号替换单引号来逃避不安全字符串有助于调解（缓解？）SQL注入漏洞。但就其本身而言，它不能保证代码在其他方面不易受到攻击。

相应输入的可能重复？“Username:Me Password 0x02BB 1=1”…@BobJohn相应的输入应该是unicodeʻ-我们假设整个输入已经是unicode，然后稍后转换为ascii。但是如果说转义机制正在寻找它，那么有各种各样的隐藏方法，例如：nchar（0x02BB）nchar（0x02BA+1）等等。我尝试了nchar密码字段中的（0x02BB）或nchar（0x02BA+1）1=1，但不起作用。@BobJohn:要利用此类漏洞，需要进行字符集转换。例如，表单发送编码为UTF8的数据，应用程序服务器处理UTF8编码，值被“转义”，然后，SQL文本通过字符集转换运行，一些UTF8字符被转换为单引号。该漏洞是数据中的特殊字符，这些字符未被“escape”函数识别为单引号，但后来被转换（通过字符集转换）为单引号。

$sql = some_other_function($sql);