Php& Sql 注入 - UTF8 POC

Question

有很多关于addslashes和mysql_real_escape函数如何不安全地防止注入的讨论。事实上，即使像 Wordpress 这样的大型框架或 CMS 也在使用这个功能，而且到目前为止它们都做得很好。

我知道使用 GBK 字符集时有一些特定的场景，或者可以使用 utf8_decode 来注入一些 sql 代码，或者一些简单的示例，例如 1' OR 1 -- 当有一个简单的情况时可以使用涉及到的地方。

然而，经过一些研究后，如果字符集是 UTF-8，则似乎很难将某些内容注入到使用 addslashes 或 mysql_real_escape 的简单查询中，让我们承认，这是最常见的情况。

因此，鉴于这个新手脚本，请提供一个sql注入POC（记住UTF-8字符集）

$mysql['username'] = addslashes($_POST['username']);
$mysql['password'] = addslashes($_POST['password']);

$sql = "SELECT *
FROM users
WHERE username = '{$mysql['username']}'
AND password = '{$mysql['password']}'";

更新 - 我只需要一个简单的示例，而不是完整公开该过程。即使是来自谷歌的链接也可能有效。

Answer 1

更新2：

经过进一步研究，5.0.77之前的MySQL版本单独与SET NAMES结合使用时可能容易受到GBK问题的影响。早些时候人们认为只有 5.0.22 及更早版本容易受到攻击。

这意味着，如果您使用 5.2 之前的 PHP 版本（其中引入了 mysql_set_charset/mysqli_set_charset），您的代码可能在特定情况下容易受到攻击，精心打造的条件。

如果您无法使用 PHP 5.1，请确保您使用的是 MySQL 5.0.77 或更高版本。 5.0.77“仅”发布了两年，但已被推送到 RHEL/CentOS 5.x 的存储库中，RHEL/CentOS 5.x 是更流行的发行版，坚持使用 MySQL 5.0.x 系列和 PHP 5.1.x 系列。

升级吧，人们！

---

更新1：最近的另一个问题发现了GBK 的来源： MySQL 中的错误修复5.0.22。早于此版本的版本在使用 mysql_real_escape_string 以外的任何内容与 mysql_set_charset而不是只是SET NAMES< /代码>。 mysqli 等效名称为 mysqli_set_charset。

PDO 中似乎没有与 mysql_set_charset 等效的内容。这可能是因为它可以使用 MySQL 本机准备好的语句，这可能不受问题的影响，或者 SET NAMES 是否足以让其底层转义机制按预期工作。

无论如何，如果您使用 5.0.22 5.0.77 之前的任何 MySQL 版本，并且没有非常小心地确保您只传递已知字符集的字符串< /strong>，你可能会发现自己很容易受到攻击。

我将保留原始帖子的其余部分不变，但我已经更新了 tldr。

---

有很多关于addslashes和mysql_real_escape函数如何不安全地防止注入的讨论

这是正确的一半。使用addslashes来防止SQL注入是完全错误的，因为它不能保证为所有数据库提供正确的转义方法，主要是因为它添加了反斜杠，有时转义机制完全不同。

如果您陷入了被称为“mysql”扩展（而不是使用 PDO 或 mysqli）的史前垃圾堆的贫民窟，那么 mysql_real_escape_string 是您在使用时获得的最佳保护之一。需要将一些 SQL 连接在一起。

我知道使用GBK字符集时有一些特定的场景，或者可以使用utf8_decode注入一些sql代码

您可能正在考虑创建格式错误的 UTF-8 序列，但是我只将其视为 XSS 机制，绝不是 SQL 注入机制。使用 iconv 运行字符串>//IGNORE//TRANSLIT 应该是足够好的保护（通常通过在错误序列处截断字符串，这是一种可接受的故障模式当你受到攻击时 - - 合法请求中不应出现格式错误的序列）。

此外，虽然非拉丁语言中有大量的“引号”字符，但 MySQL 相当不错，实际上只遵守标识符的反引号和双引号以及字符串值的单引号。

进一步考虑一下，如果将其视为不同的字符集，则另一个字符集中可能存在一些字符序列，其中可能在中间包含单引号。然而，addslashes 很可能完全不了解字符集，而只对原始字节起作用。它会在序列中间插入一个反斜杠，然后将其炸毁。然而，这应该只会导致有关错误字符集信息的抱怨。

另一方面，mysql_real_escape_string 是根据内置连接字符集的知识而设计的，因此如果它看到的是序列而不是引号，则不会转义序列。但是，因为它会将其识别为序列而不是引用，所以根本没有危险。

最终，如果您认为这是一个问题，您有责任确保仅接受预期字符集的输入，并在不匹配时将所有输入转换为您所需的字符集。这很少会妨碍合法的请求。

---

tl;dr: 除非您使用的是非常旧的 MySQL 版本和/或不能确保您的数据采用已知良好的字符集，否则不必担心。始终使用特定于数据库的转义机制以获得最大的安全性，并始终假设用户是来抓你的。