Php&Sql Injection - UTF8 POC

Question

有很多关于addslashes和mysql_real_escape函数如何防止注入安全的讨论.事实上,即使像Wordpress这样的大型框架或CMS正在使用这些功能,他们到目前为止还做了一项神工作.

我知道在使用GBK字符集时有一些特殊情况,或者可以使用utf8_decode来注入一些sql代码,或者1' OR 1 --在有简单涉及的地方时可以使用这样的一些简单示例.

然而,经过一些研究后,如果charset是UTF-8并且让我们承认,使用addslashes或mysql_real_escape这样的简单查询就很难注入,这是最常见的情况.

所以,鉴于这个新手脚本,请提供一个sql注入POC(记住UTF-8 charset)

$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版本在单独使用时可能容易受到GBK问题的影响SET NAMES.之前认为只有5.0.22及更早的人是脆弱的.

这意味着,如果你使用的PHP版本之前到5.2,其中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:另一个最近的问题揭示了GBK的来源:MySQL 5.0.22中的错误修正.版本比这更早严重使用比其他任何时候容易mysql_real_escape_string 与结合 ,而不是只.mysqli equivilent被命名.mysql_set_charset SET NAMESmysqli_set_charset

mysql_set_charset在PDO中似乎没有等效的.这可能是因为它可以使用MySQL本机预处理语句,这可能不受问题影响,或者是否SET NAMES足以使其底层转义机制按预期工作.

无论如何,如果你使用任何MySQL版本之前5.0.22 5.0.77,而不是采取极端谨慎,以确保你只传递字符串在已知的字符集,你会发现自己容易受到攻击.

我将原始帖子的其余部分保留为未修改,但我更新了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版本和/或没有确保你的数据是一个已知良好的字符集,否则不是问题.始终使用特定于数据库的转义机制来实现最大程度的安全性,并始终假设用户已经离开了.