pdo mysql ascii_PDO准备好的语句是否足以阻止SQL注入？

最新推荐文章于 2024-06-20 20:49:37 发布

浔阳咸鱼

最新推荐文章于 2024-06-20 20:49:37 发布

阅读量92

点赞数

文章标签： pdo mysql ascii

本文链接：https://blog.csdn.net/weixin_29612623/article/details/113636569

版权

简短的回答是NO，PDO准备不会保护您免受所有可能的SQL注入攻击。对于某些不起眼的边缘案例。

我正在调整这个答案来谈论PDO ......

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

攻击

那么，让我们从展示攻击开始......

$pdo->query('SET NAMES gbk');

$var = "\xbf\x27 OR 1=1 /*";

$query = 'SELECT * FROM test WHERE name = ? LIMIT 1';

$stmt = $pdo->prepare($query);

$stmt->execute(array($var));

在某些情况下，这将返回超过1行。让我们剖析一下这里发生了什么：选择一个字符集$pdo->query('SET NAMES gbk');

为了使这种攻击起作用，我们需要服务器在连接上期望的编码既可以'用ASCII 进行编码，0x27 也可以有一些字符的最终字节是ASCII \即0x5c。事实证明，会默认在MySQL 5.6支持5个这样的编码：big5，cp932，gb2312，gbk和sjis。我们会gbk在这里选择。

现在，注意SET NAMES这里的使用非常重要。这会将字符集设置为“服务器”。还有另一种方法，但我们很快就会到达那里。

有效载荷

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

我们选择了这个有效载荷，因为，如果我们叫addslashes()上他，我们就插入一个ASCII \即0x5c，在之前'的字符。所以我们结束了0xbf5c27，这gbk是一个两个字符的序列：0xbf5c接下来0x27。或者换句话说，一个有效的字符后跟一个未转义的字符'。但我们没有使用addslashes()。那么下一步......

$ stmt->的execute()

这里要认识到的重要一点是，默认情况下PDO 不会执行真正准备好的语句。它模仿它们(对于MySQL)。因此，PDO在内部构建查询字符串，mysql_real_escape_string()在每个绑定的字符串值上调用(MySQL C API函数)。

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

因此调用mysql_real_escape_string()插入反斜杠，我们'在“转义”内容中有一个自由悬挂的字符！事实上，如果我们看一下$var在gbk字符集，我们会看到：缞'或1 = 1 / *

这正是攻击所需要的。

查询

这部分只是一种形式，但这里是渲染的查询：SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1

恭喜，您刚刚使用PDO准备语句成功攻击了一个程序......

简单修复

现在，值得注意的是，您可以通过禁用模拟的预准备语句来防止这种情况：$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

这通常会导致真正准备好的语句(即数据在查询的单独数据包中发送)。但是，请注意，PDO将无声地回退到模拟MySQL本身无法准备的语句：可以在手册中列出的那些语句，但要注意选择适当的服务器版本)。

正确的修复

这里的问题是我们没有调用C API mysql_set_charset()而不是SET NAMES。如果我们这样做，我们会很好，只要我们从2006年开始使用MySQL版本。

如果您使用的是较早的MySQL版本，那么错误的mysql_real_escape_string()意思是无效的多字节字符，例如那些在我们的有效载荷被视为单字节转义的目的，即使客户端已正确通知连接编码的，因此这种攻击仍然成功。该错误是固定在MySQL 4.1.20，5.0.22和5.1.11。

但最糟糕的是，直到5.3.6 PDO才公开C API mysql_set_charset()，因此在以前的版本中，它无法阻止每次可能命令的攻击！它现在作为DSN参数公开，应该使用它代替 SET NAMES ...

拯救恩典

正如我们在开始时所说的，为了使这种攻击起作用，必须使用易受攻击的字符集对数据库连接进行编码。 utf8mb4是不容易，但可以支持所有的 Unicode字符：所以你可以选择使用的是代替，但它只是从MySQL 5.5.3可用。另一种选择是utf8，它也不易受攻击，可以支持整个Unicode 基本多语言平面。

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

安全的例子

以下示例是安全的：

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');