一个电商后台的属于管理员登录了自己的账号，浏览着用户反馈。站脚他点开了一条看起来普通的本漏留言，页面瞬间卡了一下，洞危然后恢复正常。属于他没在意。站脚三天后，本漏数据库里三万条用户订单记录出现在一个境外论坛上，洞危标价两千美元。属于

那条留言里藏了一段脚本。站脚这就是本漏XSS，跨站脚本漏洞。洞危它不像SQL注入那样直接对着数据库开枪，属于它瞄的站脚是人——准确地说，是本漏浏览器。

它偷的不是数据，是信任

很多人觉得XSS就是弹个alert框，顶多算个恶作剧。这种认知放在2005年可能还说得过去。现在？XSS能做的事情远超大多数开发者的想象。

攻击者通过XSS注入的JavaScript代码，运行在受害者的浏览器里，用的是受害者的身份。这意味着什么？你的银行页面可以正常显示，但每一笔转账的收款账号已经被悄悄改成了攻击者的。你的邮箱可以正常登录，但所有收到的邮件都会密送一份到外部地址。页面上那个“确认支付”的按钮，点击后真正发出去的请求可能和你看到的完全不是一回事。

更隐蔽的是会话劫持。服务端靠Cookie里的Session ID识别用户身份。XSS拿到这个ID，攻击者不需要你的密码，直接在另一台机器上恢复你的登录状态。双因素认证？在这一步面前形同虚设。

一个存储型XSS能毁掉整站

反射型XSS需要诱导受害者点击特定链接才能触发，存储型XSS不用。恶意脚本被存进数据库——评论区、用户昵称、商品评价、客服工单——任何访问该页面的用户都会中招。管理员也不例外。

我见过一个真实案例：某SaaS平台的工单系统存在存储型XSS。攻击者提交了一条工单，内容里嵌了脚本。客服人员打开工单查看时，脚本在后台静默执行，创建了一个新的管理员账号。整个过程不到两秒，没有任何弹窗，没有任何异常提示。从提交工单到拿到管理员权限，总共花了不到一分钟。

这就是为什么存储型XSS在漏洞赏金项目里通常被定级为高危甚至严重。它的杀伤链极短，不需要社工，不需要诱导点击，存进去就等着收网。

前端框架没有免疫这件事

React、Vue、Angular默认会对插值做转义，这确实挡住了大部分低级XSS。但危险来自那些“逃生舱口”。React的dangerouslySetInnerHTML，Vue的v-html，Angular的bypassSecurityTrustHtml——名字都在提醒你危险，但项目赶工期的时候，没人细看文档。

还有一种情况更常见：后端拼接HTML返回给前端。模板引擎的自动转义被关掉了，因为“富文本需要保留格式”。富文本编辑器如果配置不当，就是XSS的直通车。用户以为自己在写加粗和斜体，实际上可以插入任意script标签。

危害的终局是业务失控

XSS单独拿出来看，是一个客户端漏洞。但它从来不是孤立存在的。它可以是CSRF的跳板，可以是钓鱼攻击的载体，可以是蠕虫的传播引擎。2005年MySpace的Samy蠕虫，靠XSS在一天内感染了一百多万用户。二十年过去了，同样的手法换个壳子依然管用。

对企业来说，XSS的真正代价不是漏洞本身，而是后续的连锁反应：用户数据泄露、品牌信任崩塌、合规处罚、业务中断。修复一个XSS可能只需要几行代码，但修复用户被偷走的信任，代价要高得多。

开发者在写每一行输出到页面的代码时，都应该假设用户输入是充满敌意的。这不是偏执，这是基本素养。