上周三凌晨两点，检测我正打算关掉电脑睡觉，攻击手机突然弹出一条告警：某客户后台的请检留言板接口在十分钟内触发了47次XSS拦截规则。点开日志一看，查否攻击载荷清一色是输入<script>alert(1)</script>——连变种都懒得写，像是字符有人拿扫描器批量跑了一遍。我顺手翻了翻那条留言的检测原始内容，发现攻击者把payload塞在了“昵称”字段里，攻击而前端表单压根没做长度限制。请检这就是查否今天想聊的事：当你看到“检测到XSS攻击请检查是否输入了HTML字符”这句提示时，背后到底发生了什么。输入

先把这个提示拆开看。字符它其实包含两层意思：第一，检测系统识别到了疑似跨站脚本的攻击输入；第二，系统建议你检查是请检否混入了HTML标签。但很多开发者的第一反应是“我把<和>转义了不就完了？”——这个想法对了一半。转义确实能挡住大部分反射型XSS，但存储型XSS和DOM型XSS根本不走你那个转义函数。比如我见过一个案例，后端把用户输入存进数据库时做了HTML实体编码，前端却用innerHTML把内容拼进页面，结果<script>被浏览器二次解析，照样弹窗。

更隐蔽的是属性里的XSS。假设有个搜索框，代码写成<input value="用户输入">，你只过滤了尖括号，攻击者输入" onmouseover="alert(1)，闭合掉value属性后直接注入事件处理器。这时候日志里可能连<script>的影子都看不到，但XSS已经成了。所以那句提示里的“检查是否输入了HTML字符”其实是个简化说法——真正要查的是所有能改变DOM结构的字符，包括引号、反引号、括号、甚至反斜杠。

我习惯把XSS防御分成三个层次来看。第一层是输入验证，但别指望黑名单，<script>能写成<scr\0ipt>或者用<img src=x onerror=alert(1)>绕过。第二层是输出编码，这个必须根据上下文来：HTML正文用HTML实体，属性值用属性编码，JavaScript变量用JS转义，URL参数用URL编码。第三层是内容安全策略（CSP），这玩意儿才是兜底的。我自己的博客就开了script-src 'self'，就算哪天手滑漏了转义，浏览器也会直接拒绝执行内联脚本。

说个真实的翻车现场。去年帮朋友看一个老系统，留言板功能用了某国产富文本编辑器，后端过滤规则是正则匹配<script[^>]*>.*?</script>。攻击者提交了<scr<script>ipt>alert(1)</scr<script>ipt>，正则匹配掉中间那层后，剩下的字符重新拼接成了完整的<script>。这种嵌套绕过在CTF里是基本功，但在生产环境里照样能骗过不少WAF。所以看到“检测到XSS攻击”的告警，别只盯着有没有HTML标签，得把整个输入丢进解码器里跑一遍——URL解码、HTML解码、JS解码，有时候还要算上UTF-7。

最后给个可操作的检查清单。打开你的代码，找到所有接收用户输入的地方，然后问自己四个问题：这个数据会出现在HTML标签之间吗？会出现在属性值里吗？会出现在<script>块里吗？会出现在URL的href或src里吗？每个问题的答案对应不同的编码函数。如果实在拿不准，就上OWASP的Java Encoder或者DOMPurify，别自己写正则。至于那句“请检查是否输入了HTML字符”，把它当成一个提醒而不是解决方案——真正的修复动作永远在代码里，不在提示框里。