如果不设置htmlspecialchars字符集，而不设置HTTP头字符集，那么UTF-7不可能吗？

Question

我想再检查一遍，相信这会对其他人有帮助。如果有人在代码中使用htmlspecialchars($var)，并且在5.4之前运行PHP版本，那么他们可以使用utf-7 XSS。这是既定的。假设即使头内容字符集为utf-8，站点仍然向utf-7 XSS开放，这是否正确，因为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字符串调用htmlspecialchars之后，您必须使用htmlspecialchars转换该字符串。这个字符集转换是一个单独的HTML转义操作.

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

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

真正的UTF-7攻击的发生并不是由于缺少HTML编码，而是因为浏览器将页面视为包含UTF-7字节的页面，而这不是有意的。很容易阻止这种情况的发生，方法是在HTTP Content-Type头(如SilverlightFox +1所示)中或在页面中的任何用户内容之前包含的<meta>元素中包含一个显式字符集声明。