对宽字节的深入了解 |
您所在的位置：网站首页 › 无法转换字符字节为宽字符吗为什么 › 对宽字节的深入了解 |
对宽字节的深入了解
|
01 背景知识
字符集
在了解宽字节注入之前，我们先来看一看字符集是什么。字符集也叫字符编码，是一种将符号转换为二进制数的映射关系。 几种常见的字符集： ASCII编码：单字节编码latin1编码：单字节编码gbk编码：使用一字节和双字节编码，0x00-0x7F范围内是一位，和 ASCII 保持一致。双字节的第一字节范围是0x81-0xFEUTF-8编码：使用一至四字节编码，0x00–0x7F范围内是一位，和 ASCII 保持一致。其它字符用二至四个字节变长表示。宽字节就是两个以上的字节，宽字节注入产生的原因就是各种字符编码的不当操作，使得攻击者可以通过宽字节编码绕过SQL注入防御。 通常来说，一个gbk编码汉字，占用2个字节。一个utf-8编码的汉字，占用3个字节。在php中，我们可以通过输出 echo strlen("和"); 来测试。当将页面编码保存为gbk时输出2，utf-8时输出3。 除了gbk以外，所有ANSI编码都是2个字节。ansi只是一个标准，在不同的电脑上它代表的编码可能不相同，比如简体中文系统中ANSI就代表是GBK。 02 概述首先我们了解下宽字节注入，宽字节注入主要是源于程序员设置数据库编码与PHP编码设置为不同的两个编码那么就有可能产生宽字节注入 数据提交到MySQL数据库，需要进行字符集的转换，使得MySQL数据库可以对数据进行处理，这一过程一般有以下三个步骤： 收到请求，将请求数据从 character_set_client ->character_set_connection。内部操作，将数据从character_set_connection-> 表创建的字符集。结果输出，将数据从表创建的字符集 -> character_set_results。当执行set names "charset"，相当于执行set character_set_client = charsetset character_set_connection = charsetset character_set_results = charset client 指的是PHP程序 connection 指的是PHP客户端与MySQL服务器之间连接层 results 指的是MySQL服务器返回给PHP客户端的结果 MySQL常见的乱码问题就是这三个字符集的设置不当所引起的。 宽字符是指两个字节宽度的编码技术，如UNICODE、GBK、BIG5等。当MYSQL数据库数据在处理和存储过程中，涉及到的字符集相关信息包括： （1） character_set_client:客户端发送过来的SQL语句编码，也就是PHP发送的SQL查询语句编码字符集。（2） character_set_connection:MySQL服务器接收客户端SQL查询语句后，在实施真正查询之前SQL查询语句编码字符集。（3） character_set_database:数据库缺省编码字符集。（4） character_set_filesystem:文件系统编码字符集。（5） character_set_results:SQL语句执行结果编码字符集。（6） character_set_server:服务器缺省编码字符集。（7） character_set_system:系统缺省编码字符集。（8） character_sets_dir:字符集存放目录，一般不要修改。宽字节对转义字符的影响发生在character_set_client=gbk的情况，也就是说，如果客户端发送的数据字符集是gbk，则可能会吃掉转义字符\，从而导致转义失败。 例如说PHP的编码为 UTF-8 而 MySql的编码设置为了 SET NAMES 'gbk' 或是 SET character_set_client =gbk，这样配置会引发编码转换从而导致的注入漏洞。 03 addslashes，mysql_real_escape_string的区别 （1）ASCII（NULL）字符\x00， （2）换行字符\n，addslashes不转义 （3）回车字符\r，addslashes不转义 （4）反斜杠字符\， （5）单引号字符‘， （6）双引号字符“， （7）\x1a，addslashes不转义 1.AddSlashes()首先来观察一下是如何通过构造吃掉转义字符的 先将less 34的网页编码换成gbk 加上一些输出 echo "Before addslashes(): " . $uname1 . ""; $uname = addslashes($uname1); $passwd= addslashes($passwd1); echo "After addslashes(): " . $uname . ""; //echo "username after addslashes is :".$uname .""; //echo "Input password after addslashes is : ".$passwd; // connectivity mysql_query("SET NAMES gbk"); @$sql="SELECT username, password FROM users WHERE username='$uname' and password='$passwd' LIMIT 0,1"; echo "SQL Statement: " . $sql . "";POST提交 uname=%df' or 1#&passwd=1%df即ASCII码十六进制为df的字符 ß （注：%df为URL编码，URL编码即是255个ASCII字符的十六进制数值加上一个前置的%，可参考：http://www.w3school.com.cn/tags/html_ref_urlencode.html） POST提交 uname=ß' or 1#&passwd=1可以的到和提交%df一样的效果 现在来观察一下页面的输出 Before addslashes(): �' or 1# After addslashes(): 運' or 1#（注意在网页编码为UTF-8的时候 運 字是无法被显示的） After addslashes(): �\' or 1#addslashes()函数只是对单引号进行了转义处理，df字符没有做任何处理，在网页编码为GBK时，df 和 \ 字符合并成了一个gbk字符 運 在注入操作的时候，合并的过程是在MYSQL执行查询操作的时候 SELECT username, password FROM users WHERE username='�\' or 1#' and password='1' LIMIT 0,1#注意此时输入的引号并没有引发闭合 mysql_query("SET NAMES gbk");#由于客户端指定了编码gbk SELECT username, password FROM users WHERE username='運' or 1#' and password='1' LIMIT 0,1#查询语句由utf-8转向gbk编码，df 和 5c (即\)合并成为了一个gbk字符理解了这个过程，再来看看GBK编码，编码的范围为 8140-FEFE，首字节在 81-FE 之间，尾字节在 40-FE 之间，字符 \ 的ASCII码为5C，在其低位范围内，就可能被吃掉，并且能吃掉它的字符不仅只有0xdf 取一个实验一下（参考： http://www.bo56.com/gbk汉字内码扩展规范编码表） 比如 乗 字符，GBK编码 815C 那么构造 uname=%81' or 1#&passwd=1另外，GB2312编码范围是A1A1－FEFE，其中汉字编码范围：B0A1-F7FE，即高位A1~FE，低位A1~FE，字符 \ 的ASCII码为5C，不在其低位范围内，自然不会被吃掉。 2.mysql_real_escape_string()Less 36和Less 34用一样的payload注入，因此看不出来addslashes()和mysql_real_escape_string()的区别 参考：http://www.laruence.com/2010/04/12/1396.html 解释一下这个输出， addslashes函数读取每个字节，915c按照两个字节读取，发现5c后进行转义: 915c --> 915c5c 控制台为gbk编码所以显示 慭\ 第二个第三个输出都是一个原理 对于mysql_real_escape_string()函数，需要注意在使用mysql_set_charset("gbk")后，没有进行转义操作（注意看上面的代码）， 也就是说mysql_real_escape_string()函数正确读取了gbk字符（而不是两个ASCII字符，需要注意UTF-8对于ASCII字符的编码是和ASCII码相同的）， 前面三种都属于一种 “误转义” ，因此，对于宽字节注入，可以使用第四种方式避免 来实验一下 参考：https://www.leavesongs.com/PENETRATION/mutibyte-sql-inject.html mysql_real_escape_string |
【本文地址】
今日新闻 |
推荐新闻 |