mysql字符编码 seebug_Mysql字符编码利用技巧

本文探讨了MySQL字符编码在CTF题目中的利用技巧,通过一个实例展示了如何利用latin1字符绕过PHP判断。深入分析了字符集转换过程,解释了特定字符可以被忽略的原因,并讨论了MySQL UTF8特性和限制,指出MySQL的utf8实际上是阉割版,建议使用utf8mb4支持完整UTF-8编码。
摘要由CSDN通过智能技术生成

0x01 由某CTF题解说起

小密圈里有人提出的问题,大概代码如下:

ce0042ceee9c7cc39ae70d5d33167a02.png

看了一下,明显考点是这几行:

if ($username === 'admin') {

if ($_SERVER['REMOTE_ADDR'] !== '127.0.0.1') {

die('Permission denied!');

}

}

$result = $mysqli->query("SELECT * FROM z_users where username = '{$username}' and password = '{$password}'");

本文中利用Â等latin1字符来绕过php的判断。这个CTF也是用同样的方法来解决:

f2415026947110da0a006eb16ccdf5e3.png

可见,我传入的username=admin%c2,php的检测if ($username === 'admin')自然就可以绕过的,在mysql中可以正常查出username='admin'的结果。

0x02 Trick复现

那么,为什么执行SELECT * FROM user WHERE username='admin\xC2' and password='admin'却可以查出用户名是admin的记录?

刚好这段时间有人问我为什么在他的计算机上无法复现,我们来深入研究研究。

编写如下代码:

$mysqli = new mysqli("localhost", "root", "root", "cat");

/* check connection */

if ($mysqli->connect_errno) {

printf("Connect failed: %s\n", $mysqli->connect_error);

exit();

}

$mysqli->query("set names utf8");

$username = addslashes($_GET['username']);

/* Select queries return a resultset */

$sql = "SELECT * FROM `table1` WHERE username='{$username}'";

if ($result = $mysqli->query( $sql )) {

printf("Select returned %d rows.\n", $result->num_rows);

while ($row = $result->fetch_array(MYSQLI_ASSOC))

{

var_dump($row);

}

/* free result set */

$result->close();

} else {

var_dump($mysqli->error);

}

$mysqli->close();

然后在数据库cat中创建表table1:

CREATE TABLE `table1` (

`id` int(10) unsigned NOT NULL AUTO_INCREMENT,

`username` varchar(255) COLLATE latin1_general_ci NOT NULL,

`password` varchar(255) COLLATE latin1_general_ci NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;

我特地将字符集设置为latin1,其实默认情况下,Mysql的字符集就是latin1,没必要写明。

插入一个管理员账户:

INSERT `table1` VALUES (1, 'admin', 'admin');

然后,我们访问http://localhost/test.php?username=admin%c2,即可发现%c2被忽略,Mysql查出了username=admin的结果:

1508ab6b1797f23fd626260a0794e0a3.png

假设我们将table1表的字符集换成utf8,就得不到结果了。

0x03 Mysql字符集转换

经过0x02中对该Mysql Trick的复现,大概也能猜到原理了。

造成这个Trick的根本原因是,Mysql字段的字符集和php mysqli客户端设置的字符集不相同。

set names utf8 的意思是将客户端的字符集设置为utf8。我们打开mysql控制台,依次执行SHOW VARIABLES LIKE 'character_set_%';、set names utf8;、SHOW VARIABLES LIKE 'character_set_%';,即可得到如下结果:

9f5cef65e2dbfaf2d138da41bed74ed7.png

如上图,在默认情况下,mysql字符集为latin1,而执行了set names utf8;以后,character_set_client、character_set_connection、character_set_results等与客户端相关的配置字符集都变成了utf8,但character_set_database、character_set_server等服务端相关的字符集还是latin1。

这就是该Trick的核心,因为这一条语句,导致客户端、服务端的字符集出现了差别。既然有差别,Mysql在执行查询的时候,就涉及到字符集的转换。

2008年鸟哥曾在博客中讲解了Mysql字符集:

MySQL Server收到请求时将请求数据从character_set_client转换为character_set_connection;

进行内部操作前将请求数据从character_set_connection转换为内部操作字符集

在我们这个案例中,character_set_client和character_set_connection被设置成了utf8,而内部操作字符集其实也就是username字段的字符集还是默认的latin1。于是,整个操作就有如下字符串转换过程:

utf8 --> utf8 --> latin1

最后执行比较username='admin'的时候,'admin'是一个latin1字符串。

0x04 漏洞成因

那么,字符集转换为什么会导致%c2被忽略呢?

说一下我的想法,虽然我没有深入研究,但我觉得原因应该是,Mysql在转换字符集的时候,将不完整的字符给忽略了。

举个简单的例子,佬这个汉字的UTF-8编码是\xE4\xBD\xAC,我们可以依次尝试访问下面三个URL:

http://localhost:9090/test.php?username=admin%e4

http://localhost:9090/test.php?username=admin%e4%bd

http://localhost:9090/test.php?username=admin%e4%bd%ac

可以发现,前两者都能成功获取到username=admin的结果,而最后一个URL,也就是当我输入佬字完整的编码时,将会被抛出一个错误:

97199d74c981b0e4a92673f8e56dea34.png

d7766cfe4fb92f837699a932d0442017.png

d232d0dca082f9adb25693df1984cfd6.png

为什么会抛出错误?原因很简单,因为latin1并不支持汉字,所以utf8汉字转换成latin1时就抛出了错误。

那前两次为什么没有抛出错误?因为前两次输入的编码并不完整,Mysql在进行编码转换时,就将其忽略了。

这个特点也导致,我们查询username=admin%e4时,%e4被省略,最后查出了username=admin的结果。

0x05 为什么只有部分字符可以使用

我在测试这个Trick的时候发现,username=admin%c2时可以正确得到结果,但username=admin%c1就不行,这是为什么?

我简单fuzz了一下,如果在admin后面加上一个字符,有如下结果:

\x00~\x7F: 返回空白结果

\x80~\xC1: 返回错误Illegal mix of collations

\xC2~\xEF: 返回admin的结果

\xF0~\xFF: 返回错误Illegal mix of collations

这就涉及到Mysql编码相关的知识了,先看看维基百科吧。

UTF-8编码是变长编码,可能有1~4个字节表示:

一字节时范围是[00-7F]

两字节时范围是[C0-DF][80-BF]

三字节时范围是[E0-EF][80-BF][80-BF]

四字节时范围是[F0-F7][80-BF][80-BF][80-BF]

然后根据RFC 3629规范,又有一些字节值是不允许出现在UTF-8编码中的:

ef99ef956694b50aa31238f8c2c302d3.png

所以最终,UTF-8第一字节的取值范围是:00-7F、C2-F4,这也是我在admin后面加上80-C1、F5-FF等字符时会抛出错误的原因。

0x06 Mysql UTF8 特性

那么,为什么username=admin%F0也不行呢?F0是在C2-F4的范围中呀?

这又涉及到Mysql中另一个特性:Mysql的utf8其实是阉割版utf-8编码,Mysql中的utf8字符集最长只支持三个字节,

所以,我们回看前文列出的UTF-8编码第一字节的范围,

三字节时范围是[E0-EF][80-BF][80-BF]

四字节时范围是[F0-F7][80-BF][80-BF][80-BF]

F0-F4是四字节才有的,所以我传入username=admin%F0也将抛出错误。

如果你需要Mysql支持四字节的utf-8,可以使用utf8mb4编码。我将原始代码中的set names改成set names utf8mb4,再看看效果:

fbac77ac4ed7c4acbb7940f57e7542b9.png

已经成功得到结果。

0x07 总结

本文深入研究了Mysql编码的数个特性,相信看完本文,对于第一章中的CTF题目也没有疑问了。

通过这次研究,我有几个感想:

研究东西还是需要深入,之前写那篇文章的时候并没有深入研究原理,所以心里总是很迷糊

维基百科上涵盖了很多知识,有必要的时候也可以多看看

446834a71d30acd0479540c0e3cdf1d3.png

本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/267/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值