具备htmlencode功能的标签：HTML在<textarea>中是不解析的。这样的标签还有title、iframe、noscript、noframes；textarea在HTML中的权重很高，允许html标签出现在<textarea><textarea>之间；
url编码差异
dom修正式渲染：view-source这样看到的“HTML编码”实际上是静态的；按F12键打开对应的调试工具，这些调试工具查看的源码是动态结果；浏览器在DOM渲染上进行各种修正，不同的浏览器进行的这种修正可能存在一些差异。这种修正式的渲染可以用于绕过浏览器的XSS Filter；
一种dom fuzzing的技巧：模糊测试(fuzzing)；
6.3.DOM XSS挖掘静态方法：一旦发现页面存在可疑特征，就进行人工分析，这是静态方法的代价，对人工参与要求很高
动态方法：动态方法很难完美的实现检测引擎，这实际上是一次JavaScript源码动态审计的过程
6.4.Flash XSS挖掘XFS挖掘思路：XSF即Cross Site Flash；很多网站的Flash播放器都会有XSF风险，因为这些播放器需要能够灵活加载第三方Flash资源进行播放；
Google Flash XSS挖掘：Google对它们的域分离的非常好，把那些无关紧要的内容都放到了其他域名上，这样，这个XSS就是鸡肋了；
6.5.字符集缺陷导致的XSSASCII字符集表达不了拉丁系的字符，更表达不了东亚字符，所以各种演变出现了诸多字符集，如ISO8859、GB2312、GBK、GB18030、BIG5、Shift_JIS，直到Unicode字符集出现，才看到了世界和平的曙光，但是各国的这些字符集还在沿用，不可能清零从头开始，所以这个字符的世界还是很混乱
Unicode字符集的编码方式有UTF-8、UTF-16、UTF-32、UTF-7，常见的是UTF-8与UTF-7
编码的目的是最终将这些字符正确地转换为计算机可理解的二进制，对应的解码就是将二进制最终解码为人类可读的字符
宽字符编码带来的安全问题：主要是吃ASCII字符（一字节）的现象；从前端到后端的流程中，字符集编码处理不一致可能导致SQL注入、命令执行等一系列安全问题；
UTF-7问题：UTF-7时Unicode字符集的一种编码方式，不过并非是标准推荐的，现在仅IE浏览器还支持UTF-7的解析；IE浏览器历史上出现以下好几类UTF-7 XSS（1.自动选择UTF-7编码；2.通过iframe方式调用外部UTF-7编码的HTML文件；不过现在IE限制了<iframe>只能嵌入同域内的UTF-7编码文件；3.通过link方式调用外部UTF-7编码的CSS文件；4.通过指定BOM文件头；BOM的全称为Byte Order Mark。即标记字节顺序码，只出现在Unicode字符集中，BOM出现在文件的最开始位置，软件通过识别文件的BOM来判断它的Unicode字符集编码方式）；在实际的攻击场景中，能控制目标网页开头部分的功能如下（用户自定义的CSS样式文件；JSON Callback类型的链接；）
浏览器处理字符集编码BUG带来的安全问题：标准总是过于美好，比如字符集标准，但是每个浏览器在实施这些标准时不一定就能很好地实施，所以不要轻信它们不会出现BUG
6.6.绕过浏览器XSS Filter目前，主要是IE和Chrome两大浏览器拥有XSS Filter机制，不可能有完美的过滤器
XSS Filter主要针对反射型XSS，大体上采用的都是一种启发式的检测，根据用户提交的参数判断是否是潜在的XSS特性，并重新渲染响应内容保证潜在的XSS特性不会触发
响应头crlf注入绕过
针对同域的白名单：严格来说，针对同域的白名单机制不是绕过，而是浏览器的性质，这种性质给反射型XSS的利用提供了便利，IE和Chrome在这个机制上不太一样；IE会判断Referer来源是否是本域，如果是，则XSS Filter不生效；Chrome的同域白名单机制和IE完全不一样。如果是<script>嵌入同域内的js文件，XSS Filter就不会防御，这个受CSP策略的影响；
场景依赖性高的绕过
6.7.混淆的代码为了提高漏洞挖掘的成功率，我们经常需要对各种代码进行混淆，以绕过过滤机制
浏览器的进制常识：在浏览器中常用的进制混淆有八进制、十进制和十六进制；在JavaScript中可以直接通过eval执行的字符串有八进制和十六进制两种编码方式；需要注意的是，这两种表示方式不能够直接给多字节字符编码（如汉字、韩文等），如果代码中应用了汉字并且进行进制编码，那么只能进行十六进制Unicode编码；JavaScript自身就带有两个函数可以处理这个事情：char.toString(jinzhi)（char为需要编码的单字，jinzhi为需要编码的进制，可以填写2、8、10、16或其他之类数字）、String.fromCharCode(code, jinzhi)；