多字节编码由来
我们先来看看最常用的,最小字符集是ascii,对应的二级制可以表示为:00-7F 编码 。它也是我们计算机使用最早通用的字符集。前期几乎可以表示所有英文字符。后来,更多使用计算机国家加入后,我们就想在计算机中表示中文字符。我们知道常见中文就有7000多个字符。ascii码就只有128字符,只有0-127编码位置,远远不够用了。因此,我们就开始制作更大字符集,并且保证兼容ascii编码。要支持更多字符,选择更大字符集。我们只能用多个字节来描述一个字符了。为了很好的与ascii码,区分开来!一般做法是:每个字节值都大于>7F,如果是2个字节,那么就是:[>7F][>7F]。这样编码,保证很好的与ascii区分开,并且扩大了字符集。像gb2312范围在[0xA1-0xF7][0xA1-0xFE](中间很多没有填满),它完全保证所有字节在A0之上,也就完全满足在7F之上了。
GBK编码漏洞缘由
通过上面的分析,我们知道gb2312编码是很好的跟ascii码分开了。 那么我们看看,GBK编码呢,它是完全兼容gb2312(就是说在gb2312字符集中每个字符位置,与gbk字符集里面位置完全一致,而且包含于gb2312),但是,它有2万多个字符。从上面看,只能选择往下排序了。 就是从A1A0往下排了,我们发现它编码实际范围是:[0x81-0xFE]([0x40-0x7E|0x80-0xFE] ) (GBK编码),我们发现由2个字节组成,首字节范围在7F之上,而第2个字节,有一部分在0x40-0x7E了。这就是导致bug原因。我们看看下面例子吧!
从ASCII码表中,我们知道0x40-0x7E 包含字符有:“
选择gbk编码,运行上面代码,就一条简单的命令导致出现错误,说字符串 赋值 没有结束! 呵呵,估计很多人看到这个就会认为是php 出Bug了。但是,如果我们变成$a=”誠a”,发现可以正常运行了。是不是觉得很奇葩啦!!
原因分析:我们知道文件存在磁盘都是二级制方式,无论你存什么字符,最终都是以该字符的在所选字符集中字符编码保存。php解析时候,最小分析单米是字节。无论你是多字节还是单字节字符。最终都是按照字节来处理的。“誠” GBK编码是 D55C,php按字节来解释,5C对应字符是“\” 字符。后面直接跟个‘”',相当于被转义了。 因为没有闭合,因此出现错误!。大家看出问题所在了吧,按自己处理的话,会自然把多字节拆成单字节了。这样就会出现很多奇怪问题了。
总结:通过上面讲解,我们知道了多字节编码过程,以及GBK导致简单程序出错的原因。其实,我们很多程序语言里面,都会以单个字节来解析的。这样,当你选择多字节GBK编码中文时,刚好有字节落在特殊位置,将会出现奇怪错误问题。而且,还将给系统带来本身的漏洞,后面我再说说,GBK编码缺陷,导致漏洞、以及专门利用该编码漏洞缺陷进行系统入侵!好了,先到这里了,欢迎交流!
GBK字符编码(字符集)缺陷攻击(注入)原理
上一节,我们分析了。选择不同编码可能会导致程序带来本身潜在的漏洞。这次我们以GBK编码为例,看看怎么样通过该编码注入到系统中。目前很多开源系统都存在类似的注入问题。我们先来,从一个Demo开始!
GBK字符集漏洞注入原理
1 2 3 4 | <?php $u=isset($_GET['u'])? $_GET['u']:''; $u=addslashes($u); $sql = select * from user where user='$u'; |
以上是我们写的一个测试例子(GBK编码),现在很多开源系统,比较少的进行统一参数过滤,有时候为了防止注入,就直接对参数进行转义处理。我们看看,这样一个例子,我们怎么样注入进系统!