我想仔细检查一下，并相信这对其他人有帮助。如果有人在他们的代码中使用 htmlspecialchars($var) 并且正在运行 5.4 之前的 PHP 版本，那么他们对 utf-7 XSS 是开放的。这是给定的。我是否正确假设该站点仍然对 utf-7 XSS 开放，即使标头内容字符集是 utf-8，因为 PHP 的服务器内容字符集默认为 iso-8859-1？
编辑：有人问我希望从中获利什么。我希望确保项目不会受到 utf-7 的影响，因为一些程序员似乎不倾向于设置 htmlspecialchars 的第三个参数，即字符集。如果您了解我提到的服务器字符集以及它如何适合 utf-7，那么我真的可以使用您的帮助。
假设您正在谈论将用户控制的值输出到页面，那么如果 HTTP 标头设置为 UTF-8，就像这样
Content-Type: text/html; charset=utf-8
那么XSS无法使用 UTF-7 编码实现。
该charset参数对 UTF-7 攻击没有影响。在 UTF-7 中具有特殊能力的字节是 0x2B (ASCII +)，并且htmlspecialchars()永远不会转义。
如果您想要包含在使用 UTF-7 编码的网页上的用户字符串（使用 ASCII 兼容的编码，例如 UTF-8），那么您必须使用iconv('utf-8', 'utf-7', $str)after转换该字符串调用htmlspecialcharsUTF-8 字符串。此字符集转换是对 HTML 转义的单独操作。
理论上，您可以使用htmlspecialchars($s, ENT_xxx, 'utf-7')HTML 编码已经采用 UTF-7 编码的字符串，但与 iconv 扩展不同，本机 PHPhtmlspecialchars函数不支持 UTF-7。
但这一点没有实际意义，因为现代浏览器不允许您使用 UTF-7，而且没有人故意编写 UTF-7 网页。
真正的 UTF-7 攻击不是由于缺少 HTML 编码而发生的，而是因为浏览器在无意中将页面视为包含 UTF-7 字节。Content-Type通过在 HTTP标头（如 SilverlightFox，+1 所示）中或在<meta>任何用户内容之前的页面中包含的元素中包含显式字符集声明，很容易阻止这种情况发生。