搞过SQL 注入的，应该是比较了解宽字节注入的，由于某些SQL 注入的核心是提前出线单引号来闭合前边的输入，然后在后边可以插入别的语句，联合查询等等。所以比较一般的过滤方式是将单引号转义，加一个斜杠。但此时忽略了编码的神奇。如果开发者在设置编码支持的时候，如果选择了GBK，gb18030,utf-8 等方式，实际上是支持十六位编码的。
最常见的方式，也就是在url里，在引号%27 或者是 %22 之前，加入%df, 由于0xdf 对应的大于128，所以，解析器会认为他和后边的组成了16位的编码，就会吃掉后边的字符，而后边跟着的字符，又恰恰是我们给引号添加的斜杠，%5c,于是%df 就会吃掉%5c 合并成一个字，引号重新暴露。
这种方法在XSS 不常见，但是如果某些XSS 在写过滤规则的时候，如果处理不当，还是有可能出现宽字节注入的情况，考虑如下url:
|
|
此处双引号被过滤了，变成了" ;，如下：
如果我们尝试一下采用宽字节注入，考虑构造成如图所示：
zh_CN&t=%c0%22;alert(1);
令人惊奇的是，这次注入成功了，观察代码如图：
当然，此处所遇到的问题，应该并不是前边提到的传统的形式，%c0 吃掉%5c ,因为很明显，此处没有使用斜杠转义，而是转成了" ; 只能把原因归咎于正则表达式处理的问题。
我们看到，即使当以注意到了问题所在的时候，仍然可能犯错误，而且是以意想不到的方式犯错，黑客渗透的方式，可能会以所有意想不到的形式进行。
我们将防御性代码比做成安全的城墙，那么正则过滤引擎，应该是这座安全长城的第一站，而在《Web 之困》 一书中，作者也说过，要想试图过滤掉所有的危险的编码，这几乎是不可能完成的任务。但作为开发者，比黑客再多想一些，这是应该的。
在XSS 界，拥有各种各样的形式去变形构造，在owasp 里，这篇XSS Filter Evasion Cheat Sheet 详细介绍了各种变形，以期能穷尽目前已知的各种变形手段，下次，我会对其中的变性手段，进行总结。但是，你想要过滤这所有的变形手段，几乎是不可能的，即使你过滤了他们，而引擎本身出现的错误，又会创造新的漏洞，上述例子就是这样的。