宽字节跨站漏洞多发生在GB系统编码。 对于GBK编码，字符是由两个字节构成，在%df遇到%5c时，由于%df的ascii大于128，所以会自动拼接%5c，吃掉反斜线。而%27 %20小于ascii(128)的字符就会保留。通常都会用反斜线来转义恶意字符串，但是如果被吃掉后，转义失败，恶意的xss代码可以继续运行。
什么是宽字节
GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节，实际为两字节。（英文字母占据一个字节，汉字占据两个字节）。宽字节带来的安全问题主要是吃ASCII字符（一字节）的现象。
宽字节SQL注入
先来复习下宽字节注入的形成原理：
防御方式：将 ' 转换为 \'
绕过方式：将 \消灭
常规编码
| 输入 | 处理 | 编码 | 带入SQL | 结果 |
|---|---|---|---|---|
| ' | \' |
%5c%27 | id=1\' and |
不能注入 |
GBK编码
MySQL在使用GBK编码时，会认为两个字符为一个汉字。
| 输入 | 处理 | 编码 | 带入SQL | 结果 |
|---|---|---|---|---|
| %df' | %df\' |
%df%5c%27（運） | id=運' and | 能注入 |
两个字符组合，认为是一个汉字
注：前一个ASCII码大于128才能到汉字的范围。
宽字节XSS漏洞
宽字节XSS与宽字节SQL注入的不同在于宽字节注入主要是通过
吃掉转义符再正常注入SQL语句，而宽字节XSS主要使用吃掉转义符后注入恶意xss代码。
案例1：
一般情况下，当我们发现一个输入框，想要插入xss代码在里面：
通常做法是通过闭合前面的双引号和注释掉后面的双引号来触发
" />//
但是开发人员一般为了防范我们在其中插入恶意代码，会在显示之前使用过滤器对我们的输入进行转义，我们闭合使用的"被转义为\",这样就导致我们没法闭合。
如果使用了GBK等编码，我们就可以利用宽字节xss。构造如下payload：
%c0%22 />//
%c0和%df一样，也是超出了GBK的范围，此时在执行过滤操作时，源代码就变成了
当过滤器发现了%22，然后加入转义（%5c）,但在解析的时候碰到%c0,于是%5c与%c0合并成一个特殊字符，我们的"得以保留。
下面是一个PHP的例子，在magic_quotes_gpc=On的情况下，如何触发XSS？
php header("Content-Type: text/html;charset=GBK"); ?>
<head>
<title>gb xsstitle>
head>
<script> a="$_GET['x'];?>";
script>
我们会想到，需要使用闭合双引号的方法：
gb.php?x=1";alert(1)//
在magic_quotes_gpc=Off 时源代码会变成：
由于magic_quotes_gpc=On，双引号被转义成\"导致闭合失败
由于网页头部指定了GBK编码，GBK编码第一字节（高字节）的范围是0x81～0xFE，第二字节（低字节）的范围是0x40～0x7E与0x80～0xFE。
gb.php?x=1%81";alert(1)//
此时当双引号会继续被转义为\",最终代码如下：
[0x81]\ 组合成了一个合法字符，于是我们的"被保留下来就会产生闭合，我们就成功触发了xss。
GB2312是被GBK兼容的，它的高位范围是0xA1～0xF7，低位范围是0xA1～0xFE（0x5C不在该范围内），把上面的PHP代码的GBK改为GB2312，在浏览器中处理行为同GBK，也许是由于GBK兼容GB2312，浏览器都做了同样的兼容：把GB2312统一按GBK行为处理。
宽字节注入防御
1、使用utf-8，编码宽字节注入；
ps：不仅gbk，韩文、日文等都是宽字节，都有可能存在宽字节注入漏洞。
2、过滤客户端提交的危险字符。
参考链接：
https://blog.csdn.net/qq_29419013/article/details/81205291
https://www.uedbox.com/post/14488/
http://book.2cto.com/201301/14515.html