一个SQL注入点被修复后，不属安全团队欢呼雀跃，跨站仿佛系统已经固若金汤。脚本但角落里那个被标记为“低风险”的漏洞存储型XSS，正静静等着下一个访客。危害这类漏洞常被归为“鸡肋”——不直接拖库，不属不直接提权，跨站很多报告甚至把它排在“中危”以下。脚本可事实是漏洞，XSS的危害危害被严重低估了，它远不是不属“弹个alert框证明存在”那么简单。

最直观的跨站误解是拿它和RCE比。攻击者能执行任意命令，脚本能直接控制服务器，漏洞这当然致命。危害但XSS的危害在于它绕过了一切边界。防火墙、WAF、内网隔离，这些防护在浏览器面前统统失效。攻击者不需要触碰你的服务器，他只需要在你的页面上注入一段脚本，然后等一个管理员点击。管理员浏览器里存着的session、cookie、甚至打开的VPN隧道，全都成了攻击者的跳板。这不比直接拿shell慢多少，却隐蔽得多。

我见过一个真实案例。某后台系统的搜索框存在存储型XSS，攻击者把payload藏在用户昵称里。管理员每天审核新注册用户，鼠标悬停在昵称上，脚本就执行了。它悄悄改了管理员的密码重置邮箱，然后等管理员下次忘记密码。整个过程没有触发任何告警，因为流量是正常的，请求是合法的，只是那一次“忘记密码”的邮件发到了攻击者邮箱。三天后，攻击者用新密码登录后台，导走了全部用户数据。整个攻击链里，XSS只是起手式，但没了它，后面全是空谈。

还有一种危害被反复忽略——XSS是钓鱼的最佳载体。传统钓鱼要伪造域名，要骗用户输入密码，成功率低且容易被识破。但XSS让攻击者直接在你信任的页面上画一个假登录框。用户看到的是熟悉的域名、熟悉的界面，输入的密码直接发给攻击者。这种攻击几乎无法防范，因为用户没有理由怀疑自己正在使用的网站。我甚至见过利用XSS劫持剪贴板的案例，用户在页面上复制加密货币地址，粘贴时被替换成了攻击者的地址。一笔转账，钱就没了。

别拿“现在都用HttpOnly Cookie”来安慰自己。HttpOnly确实挡了cookie窃取，但XSS能做的不只是偷cookie。它还能监听键盘、截取表单数据、发起CSRF请求、篡改页面内容。一个能执行JavaScript的页面，等于把你的浏览器变成了攻击者的傀儡。他让你看到什么，你就看到什么；你按下什么键，他都记下来。这种危害是动态的，是持续性的，远不是“修掉那个弹窗”就能了事。

更麻烦的是，XSS的修复往往不彻底。开发者习惯用正则过滤特殊字符，但绕过方式层出不穷——编码、大小写、标签嵌套、事件属性。今天堵住<script>，明天攻击者用<img src=x onerror=...>照样打进来。真正有效的修复需要全面梳理输出编码、上下文感知转义、CSP策略，这些工作量大且枯燥，所以很多团队选择打补丁式修复，修完一个又冒出一个。

如果把XSS只当成“低危”，那是拿静态的眼光看动态的威胁。攻击者从来不会按你标注的严重程度来发起攻击。他们会把XSS和其他漏洞组合，会用它做跳板，会把它变成钓鱼的完美伪装。等你意识到危害时，数据早就凉透了。下次看到扫描报告里的XSS，别急着标“低危”关闭。多想想它背后能连接什么，能撬动什么。那才是一个安全工程师该有的想象力。