一个看似人畜无害的跨站输入框，可能藏着撬开整个网站后台的脚本杠杆。2014年，漏洞英国一名青少年在知名社交平台“聚友网”的跨站个人资料栏里，塞进了一段不到二十个字符的脚本脚本。他什么都没做，漏洞只是跨站静静等着。几天后，脚本任何访问他主页的漏洞管理员，浏览器都会在后台默默执行那段代码，跨站把会话令牌发送到他的脚本服务器。他凭借这个漏洞，漏洞拿到了该平台数百万用户的跨站数据库访问权。那年他17岁。脚本

跨站脚本（XSS）的漏洞核心，就是攻击者把恶意脚本“注入”到网页里，让它在其他用户的浏览器中运行。听起来像黑客电影里的高科技？其实原理简单得令人发指——网站把你提交的内容当成代码执行了。你输入“”，它原样输出，浏览器一看，哟，这是脚本，跑吧。于是你的电脑就成了别人的提线木偶。

这种漏洞分三种玩法。反射型最直白，你点击一个带恶意参数的链接，服务器把参数弹回页面，脚本跟着执行。比如某论坛搜索框，关键词没做转义，你搜“”，搜索结果页直接弹窗。存储型更阴险，攻击者把脚本存进数据库，所有访问该页面的用户都会中招。评论区、昵称、个性签名，全是重灾区。还有基于DOM的，纯前端逻辑漏洞，服务器根本不知道发生了什么。

我见过最骚的操作，是有人用XSS劫持了某电商平台的优惠券领取接口。他往商品评价里塞了段脚本，其他用户点开评价，脚本自动发起领取请求，把优惠券转到攻击者账户。整个过程用户毫无感知，页面看起来一切正常。直到平台对账发现优惠券大量异常流转，才追查到源头——一个没做过滤的文本框。

别以为做好输入过滤就万事大吉。输出编码才是关键。你可以在服务端把用户输入里的“<”、“>”、“&”等字符转成HTML实体，让浏览器只把它们当纯文本显示。但问题在于，不同上下文需要不同编码规则。放在HTML标签里和放在JavaScript字符串里，处理方式完全不同。很多开发者只做了一层过滤，结果攻击者用编码绕过、大小写混淆、甚至利用浏览器解析差异，轻松击穿防线。

有个真实案例：某政府网站允许用户查询社保信息，查询参数直接拼进SQL语句，同时也拼进了前端脚本。开发者做了SQL注入防护，却忘了XSS。攻击者构造了个特殊链接，既绕过了SQL注入检测，又在脚本上下文里注入了恶意代码。他通过这个漏洞，窃取了数百人的身份证号和社保缴纳记录。讽刺的是，这个网站刚通过等保三级测评。

防御XSS没有银弹。你得层层设防：输入侧做白名单校验，输出侧做上下文感知编码，再加一道CSP（内容安全策略）限制脚本来源。但最根本的，是改变思维定式——永远不要信任用户输入，哪怕它看起来只是一串表情符号。我见过太多开发者在测试环境里用“”测完就宣布安全，结果上线第二天就被真实攻击打脸。

写代码的人，得时刻记着：你写的每一行输出，都可能成为别人攻击的跳板。这不是危言耸听。XSS漏洞在OWASP Top 10里待了十几年，至今没掉出前列。它不像SQL注入那样直接拿数据，但它能窃取会话、篡改页面、发起钓鱼，甚至挖矿。一个看似无害的弹窗，背后可能是整条黑色产业链。

下次你在网页上提交表单时，不妨想想：你输入的内容，是会被当作数据存储，还是被当作代码执行？这个分界线，就是安全与沦陷的距离。