php写poc,Php&Sql注入 – UTF8 POC

更新2：

After further research,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的存储库,更受欢迎的配置是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 equivilent被命名为mysqli_set_charset.

在PDO中似乎没有mysql_set_charset的等同物.这可能是因为它可以使用MySQL本机准备的语句,这可能是免受此问题的影响,还是SET NAMES是否足以让它们的底层转义机制按预期工作.

无论如何,如果您在5.0.22 5.0.77之前使用任何MySQL版本,并且不会非常小心,以确保您只传递已知字符集中的字符串,您可能会发现自己受到攻击.

我没有修改我的原始帖子,但我已经更新了tldr.

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

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

如果你被困在被称为“mysql”扩展名的史前的垃圾块的贫民区(而不是使用PDO或mysqli),mysql_real_escape_string是您需要连接在一起的一些最好的保护措施.

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注入机制.运行字符串通过iconv与// IGNORE // TRANSLIT应该是足够好的保护(通常通过截断坏序列的字符串,这是一个可接受的失败模式,当你被攻击 – 畸形的序列不应该发生在合法请求).

此外,虽然在非拉丁语言中有很多“引用”字符,但MySQL在实际上只是遵循反向标题和双引号的标识符和单引号的字符串值是相当不错的.

更多的思考,也许在另一个字符集中有一些字符序列可能包括一个单引号在中间,如果被视为一个不同的字符集.然而,非常非常有可能的是,addslash完全不了解字符集,只适用于原始字节.它会在序列的中间粘一个反斜杠,并将其吹起来.然而,这应该只是导致一些关于坏字符集信息的线条.

另一方面,mysql_real_escape_string被设计为内置了连接的字符集的知识,所以如果它看到序列而不是引用,则不会逃避序列.然而,因为它会认为它是一个序列,而不是一个报价,根本就没有危险.

最终,如果您认为这是一个问题,您有责任确保您只接受预期的字符集中的输入,如果存在不匹配,则将所有输入转换为所需的字符集.如果曾经出现合法请求,这很少.

tl; dr：除非你使用一个非常老的MySQL版本和/或没有确保你的数据是一个已知的字符集,否则不要担心.始终使用特定于数据库的转义机制来实现最大安全性,并且始终假定用户无法获得您.