1. 字符编码如何被用于绕过XSS sanitizer？ #

XSS清理器（sanitizer）的核心逻辑通常是基于特定字符集去识别并转义危险字符（比如<、>、"、'、&这些），而利用编码绕过的本质就是让sanitizer无法识别出危险字符，但浏览器在解析时会将编码后的内容还原成危险字符。常见的绕过手段包括：

• UTF-7编码绕过：
  UTF-7是一种将ASCII以外的字符编码成ASCII兼容格式的编码方案，它用+作为编码标记。比如<script>alert(1)</script>可以被编码为+ADw-script+AD4-alert(1)+ADw-/script+AD4-。如果sanitizer只针对ASCII字符集中的<script>标签做检测，就会忽略这种编码后的内容；而当浏览器以UTF-7编码解析页面时，会自动将其还原为正常的脚本标签，从而触发XSS。

• 多字节编码（如GBK、Big5）绕过：
  这类编码使用两个字节表示一个汉字，黑客可以构造特殊的多字节序列，让sanitizer误判字符边界。比如在GBK编码下，0xBF 0x3C会被浏览器解析为一个汉字，但如果sanitizer以单字节编码（如ISO-8859-1）处理这个序列，会把它拆成两个独立的字符：0xBF（无意义字符）和0x3C（即<）。如果sanitizer没有正确处理多字节边界，可能只会转义0x3C，但当浏览器以GBK解析时，0xBF和转义后的<的第一个字符&又会组成新的多字节字符，最终导致<被还原出来。

• 混合编码/无效编码序列绕过：
  有些sanitizer对无效编码序列的处理不够严谨，比如构造UTF-8的无效序列（如0xC0 0x3C），sanitizer可能因为无法识别为有效UTF-8字符而跳过转义，但浏览器在遇到无效UTF-8序列时，可能会“容错”性地将其拆分为单个字符，从而还原出<这类危险字符。

2. PHP htmlspecialchars()未指定字符集的问题及对现代浏览器的影响 #

htmlspecialchars()是PHP中常用的XSS防护函数，它会将&、<、>、"、'这些字符转成对应的HTML实体（比如<转成<）。但它的行为高度依赖第三个参数$charset，如果不指定这个参数，在不同PHP版本中默认值不同：

• PHP 5.3.0及之前：默认使用ISO-8859-1（单字节编码）
• PHP 5.4.0及之后：默认使用UTF-8

当默认编码与页面实际使用的编码不匹配时，就会引发XSS漏洞，举个典型例子：

假设页面的Content-Type是text/html; charset=UTF-8，而PHP版本是5.2（默认ISO-8859-1），代码如下：

<input type="text" value="<?php echo htmlspecialchars($_GET['username']); ?>">

黑客构造输入：%C0%22onclick=alert(1)%20%22（解码后是0xC0 " onclick=alert(1) "）

• 当htmlspecialchars用ISO-8859-1处理时，会把0x22（双引号）转成"，但0xC0会被原样保留
• 输出到页面后，浏览器以UTF-8解析：0xC0是无效的UTF-8字节，会被替换成替换字符�，而"会被还原为"，最终HTML变成：

  <input type="text" value="�"onclick=alert(1) "">
  

  这里双引号提前闭合了value属性，onclick事件被成功注入，触发XSS。

对现代浏览器的影响

现代浏览器对编码的处理更加严格：

1. 它们会优先遵循页面Content-Type指定的编码，不会随意猜测编码；
2. 对于无效的UTF-8序列，会统一替换成�，而不是尝试容错解析；
3. 大部分现代网站已经统一使用UTF-8编码，且PHP 5.4+默认charset为UTF-8，只要代码中没有手动指定错误的编码，这类问题出现的概率已经很低。

但如果你的网站仍在使用老版本PHP（<5.4）且页面编码不是ISO-8859-1，或者手动指定了错误的charset参数，现代浏览器依然可能受到这类漏洞的影响——毕竟核心问题是编码不匹配导致的转义失效，浏览器的严格处理只是降低了触发概率，并没有完全消除风险。

内容的提问来源于stack exchange，提问作者XII