Php 和 Sql 注入(inject) - UTF8 POC

Question

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

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

然而，经过一些研究，如果字符集是 UTF-8，那么似乎很难将一些东西注入(inject)到一个简单的查询中，使用 addslashes 或 mysql_real_escape，让我们承认，这是最常见的情况。

所以，鉴于这个新手脚本，请提供一个 sql 注入(inject) 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 :

After further research , 之前的 MySQL 版本5.0.77 与 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 的存储库中，这是更流行的发行版，坚持 5.0.x 系列的 MySQL 和 5.1.x 系列的 PHP。

升级吧，伙计们!

更新 1:Another recent question已揭开GBK东西的来源:A bugfix in MySQL 5.0.22 .当使用除 mysql_real_escape_string 以外的任何东西时，早于此的版本都非常容易受到攻击。结合 mysql_set_charset 而不仅仅是 SET NAMES . mysqli 等效项名为 mysqli_set_charset .

似乎没有 mysql_set_charset 的等效项在 PDO 中。这可能是因为它可以使用 MySQL 原生的预准备语句，这可能是免疫问题，或者是 SET NAMES足以使其底层转义机制按预期工作。

无论如何，如果您使用任何 MySQL 5.0.22 5.0.77 之前的版本并没有特别注意确保您只传递已知字符集中的字符串 ，您可能会发现自己容易受到攻击。

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

There is a lot of talk about how addslashes and mysql_real_escape function are not safe to prevent injections

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

如果你被困在被称为“mysql”扩展(而不是使用 PDO 或 mysqli)的史前垃圾堆的贫民窟中， mysql_real_escape_string当您需要将某些 SQL 连接在一起时，这是您获得的最佳保护之一。

I know there are some particular scenarios when using GBK charset, or utf8_decode can be used to inject some sql code

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

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

仔细考虑一下，如果将其视为不同的字符集，也许另一个字符集中的某些字符序列可能在中间包含单引号。然而，很有可能是 addslashes完全不知道字符集，只处理原始字节。它会在序列中间粘贴一个反斜杠，然后将其炸毁。但是，这应该只会导致有关不良字符集信息的提示。
mysql_real_escape_string另一方面，它是根据内置的连接字符集知识设计的，因此如果它看到序列而不是引号，它就不会转义序列。然而，因为它会将它识别为一个序列而不是一个引用，所以根本没有危险。

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

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