0×06 总结
在逐渐国际化的今天，推行utf-8编码是大趋势。如果就安全性来说的话，我也觉得使用utf-8编码能够避免很多多字节造成的问题。
不光是gbk，我只是习惯性地把gbk作为一个典型的例子在文中与大家说明。世界上的多字节编码有很多，特别是韩国、日本及一些非英语国家的cms，都可能存在由字符编码造成的安全问题，大家应该有扩展性的思维。
总结一下全文中提到的由字符编码引发的安全问题及其解决方案：
1.gbk编码造成的宽字符注入问题，解决方法是设置character_set_client=binary。
2.矫正人们对于mysql_real_escape_string的误解，单独调用set name=gbk和mysql_real_escape_string是无法避免宽字符注入问题的。还得调用mysql_set_charset来设置一下字符集。
3.谨慎使用iconv来转换字符串编码，很容易出现问题。只要我们把前端html/js/css所有编码设置成gbk，mysql/php编码设置成gbk，就不会出现乱码问题。不用画蛇添足地去调用iconv转换编码，造成不必要的麻烦。
这篇文章是我对于自己白盒审计经验的一点小总结，但自己确实在很多方面存在欠缺，文中所提到的姿势难免存在纰漏和错误，希望有相同爱好的同学能与我指出，共同进步。
这篇文章不像上篇xss的，能够举出很多0day实例来论证宽字符造成的危害。原因有二：
1.宽字符问题确实不如富文本xss那么普遍，gbk编码的cms所占的比例也比较小，怪我才疏学浅，并不能每一章都找到相应的实例。
2.注入的危害比xss大得多，如果作为0day发出来，影响很坏。但我确实在写文章以及以前的审计过程中找到不少cms存在的编码问题。
所以我用实验的形式，自己写了的php小文件，给大家作为例子，希望不会因为例证的不足，影响大家学习的效果。
例子php文件和sql文件打包下载：
链接:http://pan.baidu.com/s/1eQmUArw 提取密码:75tu
本文PDF版本：链接: http://pan.baidu.com/s/1eprLs 密码: yoyw
作者博客：http://www.leavesongs.com FROM XDSEC