如果没有设置htmlspecialchars字符集，那么UTF-7是不是可能，尽管有HTTP标头字符集？

Question

我想仔细检查这一点并相信这对其他人有帮助。如果有人在他们的代码中使用htmlspecialchars（$ var）并且在5.4之前运行PHP版本，那么他们对utf-7 XSS开放。这是给定的。我是否正确假设该网站仍然对utf-7 XSS开放，即使标题内容字符集是utf-8，因为PHP的服务器内容字符集默认为iso-8859-1？

编辑：我被问到我希望从中获利。我希望确保一个项目不容易受到utf-7的影响，因为一些程序员似乎并不倾向于设置htmlspecialchars的第三个参数，即字符集。如果您了解我提到的服务器字符集以及如何适应utf-7，那么我真的可以使用您的帮助。

Answer 1

假设您正在讨论向页面输出用户控制的值，那么如果HTTP标头设置为UTF-8，那么

Content-Type: text/html; charset=utf-8

然后使用UTF-7编码无法实现XSS。

Answer 2

charset参数对UTF-7攻击没有影响。 UTF-7中具有特殊权限的字节为0x2B（ASCII +），而htmlspecialchars()永远不会逃脱该字节。

如果您有一个用户字符串（与ASCII兼容的编码，比如UTF-8），您想要包含在使用UTF-7编码的网页上，那么您必须将其转换为在UTF-8字符串上调用iconv('utf-8', 'utf-7', $str)后使用htmlspecialchars的字符串。此charset转换是HTML转义的单独操作。

理论上，您可以使用htmlspecialchars($s, ENT_xxx, 'utf-7')对已经采用UTF-7编码的字符串进行HTML编码，但与iconv扩展名不同，本机PHP htmlspecialchars函数不支持UTF-7。

但这一点没有实际意义，因为现代浏览器不会允许你使用UTF-7而且没有人故意创作UTF-7网页。

真正的UTF-7攻击不是由于缺少HTML编码，而是因为浏览器将页面视为包含UTF-7字节（如果不是这样）。通过在HTTP Content-Type标头中包含显式字符集声明（如SilverlightFox所示，+1）或在任何用户之前页面中包含的<meta>元素中，可以很容易地停止发生这种情况内容。