一、环境搭建
创建数据表
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;
去测试结果
可以看到，结果输出正确结果了
