大家知道，防御XSS攻击的常规做法，是在后台对<、>、'、"这些字符进行转义。但有些时候，即便转义做得再到位，攻击依然可能发生。下面就从几个实际案例出发，看看这种“绕过”到底是怎么实现的。
先看一段JavaScript代码：
运行这段代码，弹窗里显示的是什么？没错，就是熟悉的尖括号 <>。代码里没有直接写尖括号，但通过Unicode转义序列 \u003c 和 \u003e 照样能输出它们。这意味着，攻击者可以用 \u003c 代替 <，用 \u003e 代替 >，从而绕过常规的字符过滤。
那怎么利用这个特性构造实际的XSS攻击呢？继续看：
test
运行后，页面上成功弹出了一个对话框。整个过程中，没有出现任何尖括号，但XSS攻击依然生效了。
再设想一个更贴近真实开发场景的例子：
假设某网站首页 https://www.xxxx.com/main.html 的代码如下：
aa
而 https://www.victim.com/getcontent 返回的内容格式是：
callback({"name":"xx"});
其中 name 的值是用户的昵称。这个例子模拟了异步拉取数据并显示到页面中的场景。
现在假设用户的昵称是：
\u003cimg src=1 onerror=alert(/xss/)\u003e
那么服务端返回的JSON数据中，昵称应该是：
\\u003cimg src=1 onerror=alert(/xss/)\\u003e
因为后台输出JSON时，通常会对反斜杠 \ 进行转义，变成 \\。这样一来，main.html 中的 callback 函数实际执行的就是：
document.getElementById("test").innerHTML = " \\u003cimg src=1 onerror=alert(/xss/)\\u003e";
结果呢？很遗憾，没有弹框。因为原来的Unicode转义序列 \u003c 被拆散了——多加的那个反斜杠让转义序列失效了。
不过，这里假设了后台对反斜杠做了转义。但在实际开发中，有些JSON输出并没有对反斜杠做处理，这时漏洞就会直接触发。
如果后台确实对反斜杠做了转义，那是不是就无解了？并非如此。这时候可以请出“半字符”来帮忙。关于半字符的原理，这里不展开细讲，直接说结论：
- 对于GB2312编码，
[0xc0]\是一个合法的编码，显示为“繺”。 - 对于UTF-8编码，在IE6下，上述组合也是一个合法的编码。
其中 [0xc0] 表示一个十六进制的字节值。
现在把昵称改成这样：
[0xc0]\u003cimg src=1 onerror=alert(/xss/) [0xc0]\u003e
服务端返回的JSON变成了：
callback({"name":"[0xc0]\\u003cimg src=1 onerror=alert(/xss/) [0xc0]\\u003e"});
由于半字符 [0xc0] 的存在，JavaScript解释器在解析这段代码时，会把它当作一个合法的字符序列，从而把 \\u003c 重新解释为 \u003c。于是，转义序列 \u003c 又回来了！最终显示的结果就是：
繺
攻击成功。上述昵称中没有出现单双引号、尖括号，所以如果后台只对这些字符做转义，是防不住的。
总结一下：
- 利用场景：输出内容在JavaScript代码中，并且被动态显示（例如使用
innerHTML）。 - 测试方法：截获请求包，将参数修改为
%c0\u003cimg+src%3d1+onerror%3dalert(/xss/)+%c0\u003e。 - 防御方法：后台对半字符、反斜杠、单双引号、尖括号都进行处理。
一切皆有可能，跨站无处不在。发挥你的想象力，总能找到新的突破点。
