0×05 iconv导致的致命后果
很多cms，不止一个，我就不提名字了，他们的gbk版本都存在因为字符编码造成的注入。但有的同学说，自己测试了这些cms的宽字符注入，没有效果呢，难道是自己姿势不对?
当然不是。实际上，这一章说的已经不再是宽字符注入了，因为问题并不是出在mysql上，而是出在php中了。
很多cms(真的很多哦，不信大家自己网上找找)会将接收到数据，调用这样一个函数，转换其编码：
iconv(‘utf-8’, ‘gbk’, $_GET[‘word’]);
目的一般是为了避免乱码，特别是在搜索框的位置。
比如我们的phithon内容管理系统v3.0
我们可以看到，它在sql语句执行前，将character_set_client设置成了binary，所以可以避免宽字符注入的问题。但之后其调用了iconv将已经过滤过的参数$id给转换了一下。
那我们来试试此时能不能注入：
居然报错了。说明可以注入。而我只是输入了一个“錦'”。这是什么原因?
我们来分析一下。“錦”这个字，它的utf-8编码是0xe98ca6，它的gbk编码是0xe55c。
有的同学可能就领悟了。\的ascii码正是5c。那么，当我们的錦被iconv从utf-8转换成gbk后，变成了%e5%5c，而后面的’被addslashes变成了%5c%27，这样组合起来就是%e5%5c%5c%27，两个%5c就是\\，正好把反斜杠转义了，导致’逃逸出单引号，产生注入。
这正利用了我之前说的，绕过addslashes的两种方式的第一种：将\转义掉。
那么，如果我是用iconv将gbk转换成utf-8呢?
我们来试试：
果然又成功了。这次直接用宽字符注入的姿势来的，但实际上问题出在php而不是mysql。我们知道一个gbk汉字2字节，utf-8汉字3字节，如果我们把gbk转换成utf-8，则php会每两个字节一转换。所以，如果\’前面的字符是奇数的话，势必会吞掉\，’逃出限制。
那么为什么之前utf-8转换成gbk的时候，没有使用这个姿势?
这跟utf-8的规则有关，UTF-8的编码规则很简单，只有二条：
1)对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。
2)对于n字节的符号(n>1)，第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。
从2我们可以看到，对于多字节的符号，其第2、3、4字节的前两位都是10，也就是说，\(0x0000005c)不会出现在utf-8编码中，所以utf-8转换成gbk时，如果有\则php会报错：
但因为gbk编码中包含了\，所以仍然可以利用，只是利用方式不同罢了。
总而言之，在我们处理了mysql的宽字符注入以后，也别认为就可以高枕无忧了。调用iconv时千万要小心，避免出现不必要的麻烦。