xss漏洞完美解决方法

上周帮朋友看一个后台系统，洞完登录框里输入 "><script>alert(1)</script>，美解回车，决方弹窗了。洞完他瞪大眼睛说“这也能行？美解”——这玩意儿1990年代就有人玩，2024年了还在线上跑着，决方挺离谱的洞完。

XSS 的美解本质就一句话：用户输入的内容被当成代码执行了。浏览器分不清哪段是决方开发者写的、哪段是洞完攻击者塞的，只要它出现在 HTML 里、美解没被正确处理，决方就会照跑不误。洞完

先搞清楚它是美解怎么进来的

三种路子。反射型最蠢，决方URL 里带个参数，服务端原样吐回页面里，比如搜索框显示“您搜索了：xxx”。存储型最狠，评论、昵称、地址这些存进数据库，谁看谁中招，一个留言能打穿整个后台。DOM 型最隐蔽，服务端啥也没干，前端 JS 自己把 location.hash 往 innerHTML 里塞，漏洞全在浏览器里发生。

我见过一个电商站，商品详情页的“规格参数”是从 URL 读取的，直接拼进 DOM。攻击者发一条链接给客服，客服点开，cookie 就飞到别人服务器上了。这种场景下，你后端过滤做得再严也没用，因为请求根本没到后端。

“过滤”为什么总是失败

很多人的第一反应是写黑名单：把 <script> 替换掉，把 onerror 删掉。这条路走不通。HTML 的解析规则复杂到超出直觉——<img src=x onerror=alert(1)> 能弹，<svg onload=alert(1)> 能弹，<body onpageshow=alert(1)> 也能弹。你封得完吗？

更别提大小写混写、HTML 实体编码、Unicode 变体这些绕过手法。黑名单是一场永远打不赢的军备竞赛。

正确的做法：按输出位置编码

核心原则只有一条——在数据输出到页面的那一刻，根据它所在的上下文做编码。不是输入时过滤，是输出时转义。

HTML 标签之间（比如 <div>这里</div>），把 & < > " ' 转成实体。HTML 属性里（比如 value="这里"），除了实体编码，属性值必须加引号。JS 变量里（比如 var x = '这里'），用 \x 或 \u 转义，别用引号包裹了事。URL 参数里，用 encodeURIComponent。

听起来麻烦？现代框架基本帮你做了。React 的 JSX 默认转义，Vue 的模板插值 { { }} 也是转义的。问题出在 dangerouslySetInnerHTML 和 v-html 上——用了它们，等于亲手关掉保护。

富文本是唯一的例外

后台编辑器要保留格式，不能全转义。这时候用白名单库，比如 DOMPurify。它的思路是：解析成 DOM 树，只保留允许的标签和属性，其余全删。别自己写正则去洗 HTML，我试过，洗不干净。

还有个容易漏的地方：把用户内容放进 <a href="..."> 时，要检查协议。 javascript:alert(1) 这种链接，点击就执行。DOMPurify 默认会拦，但自己拼字符串就容易忘。

CSP 是最后一道防线

Content-Security-Policy 响应头能告诉浏览器：只允许加载同源的脚本，禁止内联 <script> 执行。配好 script-src 'self'，就算攻击者成功注入了 <script>，浏览器也拒绝跑。

但 CSP 不是万能的。它配置复杂，容易误伤，很多老系统加不上去。而且它防不住 DOM 型 XSS 里的 innerHTML 注入——因为那压根不涉及脚本加载。所以 CSP 是兜底，不是替代编码。

一个真实案例的收尾

回到开头那个后台。我看了代码，他们用了模板引擎，但某处为了“灵活”直接拼了字符串：res.send('<h1>欢迎 ' + username + '</h1>')。改成模板变量后，问题消失。整个过程不到十分钟。

XSS 的完美解决不存在。但把“输出编码”刻进肌肉记忆，再配上 CSP 和 DOMPurify 处理富文本，能挡住 99% 的实际攻击。剩下 1%，靠的是每次写 innerHTML 时心里咯噔一下的那点警觉。