GBK字符编码（字符集）缺陷导致web安全漏洞

多字节编码由来
我们先来看看最常用的，最小字符集是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字符集漏洞注入原理

?php
$u=isset($_GET['u'])? $_GET['u']:'';
$u=addslashes($u);
$sql = "select * from user where user='$u'";

以上是我们写的一个测试例子（GBK编码），现在很多开源系统，比较少的进行统一参数过滤，有时候为了防止注入，就直接对参数进行转义处理。我们看看，这样一个例子，我们怎么样注入进系统！