xss跨站脚本漏洞修复

一个搜索框，站脚用户输入 <script>alert(1)</script>，本漏页面直接弹窗。洞修这不是站脚漏洞演示，这是本漏上周我帮朋友看的一个后台管理系统里真实发生的事。他的洞修商品搜索功能把用户输入原样拼进 HTML 返回，连基本的站脚转义都没有。修复 XSS 这件事，本漏说复杂也复杂，洞修说简单就一句话：永远不要把不可信数据当代码执行。站脚但具体怎么做，本漏坑比想象中多。洞修

先搞清楚 XSS 有几种。站脚反射型最常见，本漏恶意脚本藏在 URL 参数里，洞修服务端把它拼进响应页面，浏览器一渲染就执行。存储型更麻烦，脚本被存进数据库，每个访问该页面的用户都会中招——比如评论区、用户昵称、商品描述这些地方。还有 DOM 型，服务端压根没参与，前端 JS 从 location.hash 或 innerHTML 里取数据直接写进 DOM，照样触发。

修复的核心手段是输出编码。注意，是输出时编码，不是输入时过滤。很多开发者喜欢在入口处把 < > 替换掉，觉得万事大吉。这思路有问题：数据在数据库里被改得面目全非，哪天需要导出成 CSV 或者通过 API 返回 JSON，内容全是乱的。正确的做法是数据原样存储，在渲染到 HTML 的最后一刻做上下文相关的编码。

什么叫上下文相关？同一个字符串，放在不同位置需要的编码方式不同：

• 放进 HTML 标签内容里，编码 & < > " '
• 放进 href 或 src 属性里，还得校验协议，只允许 http: https:，否则 javascript:alert(1) 照样执行
• 放进 <script> 标签内部的 JS 变量里，得用 JavaScript 编码，不能只做 HTML 实体编码
• 放进 CSS 的 style 属性里，又是另一套规则

我见过一个案例，开发者对用户输入做了 HTML 实体编码，但把它放在了 onclick 事件属性里：onclick="doSomething(''+userInput+'')"。用户输入 ');alert(1);//，实体编码后变成 ');alert(1);//，浏览器解析 HTML 属性时先把实体解码回单引号，然后 JS 引擎执行，弹窗照旧。所以编码必须匹配数据最终所处的解析上下文。

现代前端框架在这方面帮了大忙。React、Vue 默认对插值做转义，{ userInput} 是安全的。但一旦你用 dangerouslySetInnerHTML 或者 v-html，框架的保护就失效了。我翻过不少项目代码，出事的基本都是这些地方。能用文本就用文本，实在要渲染富文本，上 DOMPurify 这类库做白名单过滤，别自己写正则——绕过的姿势太多了。

后端模板引擎也有讲究。Thymeleaf 用 th:text 是安全的，th:utext 是不转义的。Jinja2 里 { { }} 自动转义，{ % autoescape false %} 就关掉了。Go 的 html/template 会根据上下文自动选择编码方式，但 text/template 什么也不做。选错包，等于没防。

还有个容易忽略的点：HttpOnly Cookie 标记。它不能阻止 XSS 发生，但能防止攻击者通过 document.cookie 偷走会话凭证。配合 Content-Security-Policy 响应头限制脚本来源，能把危害压到最低。CSP 配置有门槛，但哪怕只加一条 script-src 'self'，也能挡掉大量外部注入。

修复完记得验证。手动测几个 payload：<img src=x onerror=alert(1)>、"><svg onload=alert(1)>、javascript:alert(1)。更省事的办法是跑一遍 OWASP ZAP 或者 Burp Suite 的主动扫描。别只测搜索框，URL 路径参数、HTTP 头里的 Referer、User-Agent，只要被回显到页面上，都是潜在的注入点。

说到底，XSS 修复没有银弹。框架默认安全，但总有开发者亲手把门打开。编码、白名单、CSP、HttpOnly，层层叠加才靠谱。每次看到 innerHTML = location.search 这种代码，我都想隔着屏幕把键盘拍他脸上。