php& SQL注入-UTF8 POC [英] Php & Sql Injection - UTF8 POC

问题描述

有很多关于addslashes和mysql_real_escape函数如何不安全地防止注入的讨论.事实是，甚至像Wordpress这样的大型框架或CMS都在使用此功能，到目前为止他们做得很出色.

There is a lot of talk about how addslashes and mysql_real_escape function are not safe to prevent injections. The truth is even the big frameworks or CMSs like Wordpress are using this functions and they do a god job so far.

我知道使用GBK字符集时有一些特殊的情况，或者可以使用utf8_decode注入一些sql代码，或者可以使用一些简单的示例(如1' OR 1 --)，当涉及到简单的地方时就可以使用.

I know there are some particular scenarios when using GBK charset, or utf8_decode can be used to inject some sql code, or some simple examples like 1' OR 1 -- that can be used when there is a simple where involved.

但是，经过一些研究，如果字符集为UTF-8且我们承认这是最常见的情况，那么似乎很难将某些东西添加到使用addlashes或mysql_real_escape的简单查询中.

However, after a bit of research it seems very hard to inject something into a simple query with addslashes or mysql_real_escape used if the charset is UTF-8 and let's admit it, this is the most common scenario.

因此，鉴于此新手脚本，请提供sql注入POC(请记住UTF-8字符集)

So, given this newbie script, pls provide a sql injection POC ( remember 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']}'";

更新-我只需要一个简单的示例，而不是对该过程的完整披露.甚至来自Google的链接也可能有效.

Update - I just need a simple example not a full disclosure of the process. Even a link from google might work.

推荐答案

更新2 :

经过进一步研究， 5.0.77 之前的MySQL版本如果单独与SET NAMES结合使用，可能会容易受到GBK问题的攻击.以前认为只有5.0.22和更早的版本易受攻击.

After further research, MySQL versions prior to 5.0.77 may be vulnerable to the GBK issue when combined with SET NAMES alone. It was earlier believed that only 5.0.22 and earlier were vulnerable.

这意味着，如果您使用的是 之前的PHP版本5.2，其中引入了mysql_set_charset/mysqli_set_charset，则在特定的精心设计条件下，您的代码可能会受到攻击.

This means that if you are using PHP versions prior to 5.2, in which mysql_set_charset / mysqli_set_charset were introduced, your code may be vulnerable under specific, well-crafted conditions.

如果您坚持使用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系列中.

If you're stuck on PHP 5.1, please ensure that you are using MySQL 5.0.77 or later. 5.0.77 is "only" two years old, but has been pushed into the repositories for RHEL/CentOS 5.x, the more popular distribution stuck with the 5.0.x series of MySQL and 5.1.x series of PHP.

获得升级，人民！

更新1 :另一个最近的问题已发现GBK内容的来源: A MySQL 5.0.22中的错误修正.当使用除mysql_real_escape_string 以外的任何内容与 结合使用时，早于此版本的版本会严重 易受攻击. function.mysql-set-charset.php"rel =" nofollow noreferrer> mysql_set_charset 而不是. mysqli对等名称为 mysqli_set_charset .

Update 1: Another recent question has uncovered the source of the GBK thing: A bugfix in MySQL 5.0.22. Versions earlier than this are severely vulnerable when using anything other than mysql_real_escape_string combined with mysql_set_charset instead of just SET NAMES. The mysqli equivilent is named mysqli_set_charset.

在PDO中似乎没有mysql_set_charset的等价物.这可能是因为它可以使用MySQL本机准备的语句(可能不受此问题的影响)，或者是SET NAMES是否足以使它们的基础转义机制按预期工作.

There does not appear to be an equivilent of mysql_set_charset in PDO. This may be either because it can use MySQL native prepared statements, which may be immune from the problem, or whether SET NAMES is enough for their underlying escaping mechanism to work as expected.

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

Regardless, if you're using any MySQL version prior to 5.0.22 5.0.77 and are not taking extreme care to ensure that you're only passing in strings in a known character set, you may find yourself open to attack.

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

I'm leaving the rest of my original post unmodified, but I have updated the tldr.

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

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

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

This is half correct. addslashes is entirely the wrong thing to use to protect against SQL injection because it is not guaranteed to provide the right escaping method for all databases, mainly because it adds backslashes and sometimes the escaping mechanism is entirely different.

如果您陷入史前史无前例的垃圾邮件区，那就是"mysql"扩展名(而不是使用PDO或mysqli)，那么mysql_real_escape_string是您在需要时可以获得的最佳保护将一些SQL连接在一起.

If you're stuck in the ghetto of the prehistoric lump of crap known as the "mysql" extension (instead of using PDO or mysqli), mysql_real_escape_string is some of the best protection you've got when you need to concatenate together some SQL.

我知道使用GBK字符集时会有一些特殊的情况，或者可以使用utf8_decode注入一些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序列，但是我只把它看作是 iconv 和//IGNORE//TRANSLIT运行字符串应该足够好保护(通常是在错误序列的位置截断字符串，这是可接受的失败模式，在受到攻击时会出现错误-合法请求中永远不会出现格式错误的序列).

You're probably thinking of creating malformed UTF-8 sequences, however I've only ever seen this as an XSS mechanism, never an SQL injection mechanism. Running strings through iconv with //IGNORE//TRANSLIT should be good enough protection (usually by truncating the string at the point of the bad sequence, which is an acceptable failure mode when you're being attacked -- malformed sequences should never happen in legitimate requests).

此外，尽管在非拉丁语言中有很多引号"字符，但MySQL相当不错，仅实际上遵循标识符的反引号和双引号以及字符串值的单引号.

Further, while there are plenty of "quote" characters in non-Latin languages, MySQL is pretty decent at only actually obeying the backtick and double quote for identifiers and the single quote for string values.

仔细考虑一下，如果将另一个字符集中的字符序列视为不同的字符集，则可能会有一些字符序列包含在中间的单引号引起来.但是，很有可能addslashes完全不了解字符集，并且只适用于原始字节.它会在序列的中间加上一个反斜杠，然后将其炸掉.但是，应该只会导致关于不良字符集信息的抱怨.

Thinking about it more, perhaps there's some sequence of characters in another character set that might include a single quote in the middle, if taken as a different character set. However, it's very, very likely that addslashes is entirely ignorant of character set, and just works on the raw bytes. It'd stick a backslash in the middle of a sequence, and blow it up. However, that should just result in a whine somewhere along the lines about bad character set information.

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

mysql_real_escape_string, on the other hand, is designed with knowledge of the connection's character set built in, so it wouldn't escape the sequence if it sees the sequence instead of a quote. However, because it would recognize it as a sequence instead of as a quote, there's no danger at all.

如果您认为这是一个问题，那么您有责任确保仅接受期望的字符集中的输入，并在不匹配的情况下将所有输入转换为期望的字符集.如果遇到合法请求，这种情况将很少发生.

Ultimately if you think this is a problem, it's your responsibility to ensure that you accept input in only the expected character sets, and transform all input to your desired character set if there's a mismatch. This will rarely if ever trip up a legitimate request.

tl; dr:不必担心，除非您使用的是非常老的MySQL版本和/或不确定您的数据是否使用已知良好的字符集.始终使用特定于数据库的转义机制来获得最大的安全性，并始终假定用户正在帮助您.

tl;dr: Not a concern unless you're using a really old MySQL version and/or aren't making sure your data is in a known-good character set. Always use database-specific escape mechanisms for maximum safetey, and always assume the user is out to get you.

这篇关于php& SQL注入-UTF8 POC的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！