如果以下陈述属实，
Content-Type: text/html; charset=UTF-8。<script>个标记。是否存在htmlspecialchars($input, ENT_QUOTES, 'UTF-8')（将&，"，'，<，>转换为相应的指定HTML实体的情况）在Web服务器上生成HTML时，是否足以防止跨站点脚本？
答案 0 :(得分：16)
htmlspecialchars()足以阻止文档创建时HTML注入您声明的限制（即不注入标记内容/不带引号的属性）。
然而，还有其他类型的注射可以导致XSS和：
没有＆lt; script＆gt;文档中的标签。
这种情况并未涵盖JS注入的所有情况。例如，您可能具有事件处理程序属性（在HTML转义中需要JS转义）：
<div onmouseover="alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!
或更糟糕的是，javascript：link（在HTML转义中需要JS转义内部的URL转义）：
<a href="javascript:alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!
通常最好避免使用这些结构，尤其是在模板化时。写<?php echo htmlspecialchars(urlencode(json_encode($something))) ?>非常繁琐。
并且......注入问题也可能发生在客户端（DOM XSS）;如果没有明确的转义，htmlspecialchars()将无法保护您免受JavaScript写入innerHTML（通常.html()在糟糕的jQuery脚本中）的错误。
而且...... XSS的原因不仅仅是注射。其他常见原因是：
允许用户创建链接，而不检查已知良好的URL方案（javascript:是最知名的有害方案，但还有更多）
故意允许用户直接或通过光标记方案（如bbcode，总是可利用）创建标记
允许用户上传文件（可以通过各种方式重新解释为HTML或XML）
答案 1 :(得分：2)
假设您没有使用较旧的PHP版本（5.2左右），htmlspecialchars是“安全的”（并且当然考虑到@Royal Bg提到的后端代码）
在较旧的PHP版本中，UTF-8字符格式错误导致此功能易受攻击（http://www.securityfocus.com/bid/37389）
我的2美分：只是通过告诉我们允许的内容来消毒/检查您的输入，而不是仅仅逃避一切/编码所有内容
即。如果有人必须输入电话号码，我可以想象允许以下字符：0123456789（）+ - 。和一个空间，但所有其他人都被忽略/剥离
同样适用于地址等。在地址中为点/块/心等指定UTF-8字符的人必须患有精神疾病......
答案 2 :(得分：-6)
据我所知，是的。我无法想象它不会避免xss的情况。如果您想要完全安全，请使用strip_tags（）