1、漏洞描述：
宽字节注入是相对于单字节注入而言的，该注入跟HTML页面编码无关，宽字节注入常见于mysql中，GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节，实际上只有两字节。宽字节带来的安全问题主要是吃ASCII字符(一字节)的现象，当%df’ 被PHP转义(开启GPC、用addslashes函数，或者icov等)，单引号被加上反斜杠\，变成了%df\’，其中\的十六进制是%5C，那么现在%df\’ = %df%5c%27，如果程序的默认字符集是GBK等宽字节字符集，则MYSQL用GBK的编码时，会认为%df%5c是一个宽字符，也就是x’，也就是说：%df\’ = %df%5c%27=x’，有了单引号可以注入了。
2、检测条件：
Php+mysql的搭配，则需要进行检测。
3、检测方法
检测时，了解了其原理为：php使用php_escape_shell_cmd这个函数来转义命令行字符串时是作为单字节处理的，而当操作系统设置了GBK、EUC-KR、SJIS等宽字节字符集时候，将这些命令行字符串传递给MySQL处理时是作为多字节处理的，如：
http://localhost/gbk.php?username=%df%27 //多字节编码
%df%27=運' //看，出单引号了，后面就可以构造了
http://localhost/test/b.php?username=%df%27or1%23
sql语句类似这样: SELECT * FROMdemo WHERE username = '運' or 1#' LIMIT 1
这样就可以注入，或者：id=%df’%20or%201=1%20limit%201,1%23&pass=4、修复方案
1、改Windows下的MySQL配置文件一般是my.ini，Linux下的MySQL配置文件一般是my.cnf，在初始化连接和字符集之后，使用SET character_set_client=binary来设定客户端的字符集是二进制的。character_set_client指定的是SQL语句的编码，如果设置为binary，MySQL就以二进制来执行，这样宽字节编码问题就没有用武之地，如：
mysql_query(”SET character_set_client=binary”);2、转义数据：一些合法的数据可能在无意中破坏SQL语句本身的格式。使用mysql_escape_string()或者所使用数据库提供的转移函数。如果没有提供这样的函数，addslashes()也是不错的最后选择。原理是：mysql_real_escape_string与addslashes的不同之处在于其会考虑当前设置的字符集，不会出现前面e5和5c拼接为一个宽字节的问题。