mysql注入-字符编码技巧

一、环境搭建

创建数据表

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，