一、环境搭建
创建数据表
CREATE TABLE `mysql_Bian_Man` (`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;
ENGINE=MyISAM
:表示数据库表的存储引擎为MyISAM。MyISAM是MySQL的一种存储引擎,它提供了全文索引、压缩等特性,但不支持事务和行级锁定。
AUTO_INCREMENT=1
:表示表中的主键(通常是名为id
的字段)的自增长起始值为1。当插入新记录时,如果没有指定主键的值,MySQL会自动为该字段分配一个递增的值。
DEFAULT CHARSET=latin1
:表示表的默认字符集为latin1。这意味着在创建表时,如果没有明确指定某个字段的字符集,那么该字段将使用latin1字符集。这一条很重要,漏洞形成就是因为这一条
COLLATE=latin1_general_ci
:表示表的默认排序规则为latin1_general_ci。排序规则决定了字符数据的比较和排序方式。在这个例子中,使用的是不区分大小写的通用排序规则。
插入数据
INSERT `mysql_Bian_Man` VALUES (1, 'admin', 'admin');
前端代码环境
<?php
$mysqli = new mysqli("localhost", "root", "root", "mysql_zhu_ru");/* check connection */
if ($mysqli->connect_errno) {printf("Connect failed: %s\n", $mysqli->connect_error);exit();
}$mysqli->query("set names utf8");
//`set names utf8` 的意思是将客户端的字符集设置为utf8
$username = addslashes($_GET['username']); //接受get传参 //if判断
if ($username === 'admin') {die('Permission denied!');
}/* Select queries return a resultset */
$sql = "SELECT * FROM `mysql_Bian_Man` 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);//printf('flag{1122312}');//这里本来是flag的位置,但这里改动了一下}/* free result set */$result->close();
} else {var_dump($mysqli->error);
}$mysqli->close();
检验
二、绕过
绕过查询
127.0.0.1/mysql_BianMan/web.php?username=admin%c2
在上图中我们可以看到,用username=admin%c2,把admin的密码查询出来了,先前测试时,用username=admin,返回了一句话。为什么会这样呢?
三、漏洞原理——Mysql字符集转换
造成这个漏洞的根本原因是,Mysql字段的字符集和php mysql客户端设置的字符集不相同
我们看mysql每个阶段所用到的字符集
这个是我数据库的每阶段字符集
character_set_server:默认的内部操作字符集
character_set_client:客户端来源数据使用的字符集
character_set_connection:连接层字符集
character_set_results:查询结果字符集
character_set_database:当前选中数据库的默认字符集
character_set_system:系统元数据(字段名等)字符集
从上面看出我的字符集基本上都是utf-8字符集,编码转换都是一样的,为什么会说漏洞出现在MySQL字符集转换呢?
不知道大家有没有注意到,前面建表所指定的字符集了吗?没错问题就出现在那
mysql> SELECT DISTINCT CHARACTER_SET_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'mysql_zhu_ru';
mysql> show table status from mysql_zhu_ru\G
那么,字符集转换为什么会导致%c2被忽略呢?
有大佬分析原因应该是,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字符串。
举个简单的例子,佬这个汉字的UTF-8编码是\xE4\xBD\xAC,我们可以依次尝试访问下面三个URL: b'\xe4\xbd\xac'
http://127.0.0.1/mysql_1.php?username=admin%e4 http://127.0.0.1/mysql_1.php?username=admin%e4%bd http://127.0.0.1/mysql_1.php?username=admin%e4%bd%ac
佬
'0b111001001011110110101100'
看到佬字utf-8是三字节
可以发现,前两者都能成功获取到username=admin的结果,而最后一个URL,也就是当我输入佬字完整的编码时,将会被抛出一个错误:
为什么会抛出错误?原因很简单,因为latin1并不支持汉字,所以utf8汉字转换成latin1时就抛出了错误。
那前两次为什么没有抛出错误?因为前两次输入的编码并不完整,Mysql在进行编码转换时,就将其忽略了。
这个特点也导致,我们查询username=admin%c2时,%c2被省略,最后查出了username=admin的结果。
四、Mysql UTF8 特性
那么,为什么username=admin%F0也不行呢?F0是在C2-F4的范围中呀?
这又涉及到Mysql中另一个特性:Mysql的utf8其实是阉割版utf-8编码,Mysql中的utf8字符集最长只支持三个字节,所以,我们UTF-8编码的范围,
UTF-8编码的每字节的范围如下:
- 对于1字节长的字符,字节的首位为0,后7位表示字符的Unicode码点。因此,1字节长的字符的范围是0x00到0x7F。
- 对于2字节长的字符,第一个字节的格式为110xxxxx,第二个字节的格式为10xxxxxx。因此,2字节长的字符的范围是0xC0到0xDF
- 对于3字节长的字符,第一个字节的格式为1110xxxx,后面两个字节的格式为10xxxxxx。因此,3字节长的字符的范围是0xE0到0xEF
- 对于4字节长的字符,第一个字节的格式为11110xxx,后面三个字节的格式为10xxxxxx。因此,4字节长的字符的范围是0xF0到0xF7
然后根据RFC 3629规范,又有一些字节值是不允许出现在UTF-8编码中的:
F0-F4是四字节才有的,所以我传入username=admin%F0也将抛出错误。
如果你需要Mysql支持四字节的utf-8,可以使用utf8mb4编码。我将原始代码中的set names改成set names utf8mb4,
五、验证测试
用上面的建表语句表创建另一个字符集为utf-8的的表,用于验证漏洞猜想
Create Table: CREATE TABLE `mysql_bian_man1` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`username` varchar(255) CHARACTER SET utf8 DEFAULT NULL,
`password` varchar(255) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
漏洞查看
我们可以看到,被绕过了,why?问题出在了字段的字符集的编码上
show full columns from mysql_bian_man1\G
我们修改齐字符集编码
alter table mysql_bian_man1 modify username varchar(255) character set utf8;
去测试结果
可以看到,结果输出正确结果了