富文本编辑器场景下的 XSS 防御方案

富文本编辑器是现代 Web 应用中不可或缺的组件，无论是博客平台、论坛、CMS 系统还是在线文档工具，都依赖它来提供图文混排的编辑体验。然而，富文本编辑器同时也是 XSS（跨站脚本攻击）的重灾区——它天生需要允许用户输入 HTML，而 HTML 中恰恰可以嵌入脚本。如何在保留丰富编辑功能的同时有效防御 XSS，是每个开发者都必须面对的问题。

XSS 的常见方式与前端防御思路

在讨论富文本场景之前，先回顾 XSS 的基本类型。

存储型 XSS 是最危险的一种。攻击者将恶意脚本提交到服务器并持久化存储（如评论、文章），当其他用户浏览该页面时脚本自动执行。富文本编辑器正是存储型 XSS 的典型入口。

反射型 XSS 通过诱导用户点击携带恶意参数的链接，服务器将参数直接回显到页面中触发执行。

DOM 型 XSS 则完全发生在浏览器端，前端 JavaScript 从不安全的来源（如 location.hash、document.referrer）读取数据并插入 DOM，导致脚本执行。

前端防御的核心原则只有一条：永远不要信任用户输入，在输出时进行上下文相关的转义或净化。对于普通文本字段，使用 textContent 而非 innerHTML 即可；对于需要渲染 HTML 的场景，则必须依赖专业的净化库。

富文本编辑器的特殊挑战

富文本编辑器与普通输入框的根本区别在于：它必须允许一部分 HTML 标签和属性通过。<p>、<strong>、<a>、<img> 等标签是正常内容，但 <script>、<iframe>、onerror 属性等则是攻击载荷。难点在于：

1. 黑名单永远不够。浏览器对 HTML 的解析极其宽容，<scr<script>ipt>、<img src=x onerror=alert(1)>、<svg onload=...> 等变体层出不穷，仅靠正则或字符串替换无法穷举。
2. 前后端职责边界模糊。前端净化可以被绕过（攻击者直接构造 HTTP 请求），后端净化如果过于激进又会破坏正常内容。
3. 粘贴内容不可控。用户从 Word、网页复制的内容可能携带大量冗余标签和隐藏脚本。

推荐方案：白名单净化 + 多层防御

第一层：前端使用 DOMPurify 进行白名单净化

DOMPurify 是目前最成熟的 HTML 净化库，它基于浏览器原生 DOM 解析器工作，能够正确处理各种畸形 HTML。配置示例：

import DOMPurify from 'dompurify';

const clean = DOMPurify.sanitize(dirtyHTML, {
  ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'u', 'a', 'img', 'ul', 'ol', 'li', 'h1', 'h2', 'h3', 'blockquote', 'code', 'pre'],
  ALLOWED_ATTR: ['href', 'src', 'alt', 'title', 'class'],
  ALLOW_DATA_ATTR: false,
  ALLOWED_URI_REGEXP: /^(?:(?:https?|mailto):|[^a-z]|[a-z+.-]+(?:[^a-z+.\-:]|$))/i
});

关键点：明确指定允许的标签和属性，禁止 data-* 属性，限制 URI 协议只允许 http、https、mailto，从而阻止 javascript: 伪协议。

第二层：后端再次净化

前端净化只是提升用户体验，攻击者完全可以绕过前端直接发送请求。后端必须使用对应语言的净化库再做一次处理，例如 Node.js 使用 sanitize-html，Java 使用 OWASP Java HTML Sanitizer，Python 使用 bleach。后端应维护与前端一致的白名单策略，确保入库数据已经安全。

第三层：渲染时设置 CSP

内容安全策略（CSP）是最后一道防线。通过 HTTP 响应头限制脚本来源，即使恶意脚本侥幸进入页面，也无法执行：

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self';

避免使用 unsafe-inline 和 unsafe-eval，对内联脚本使用 nonce 或 hash 机制。

第四层：输出时的上下文转义

即使内容已经过净化，在将数据插入不同上下文时仍需转义。例如将用户昵称插入 HTML 属性、JavaScript 变量或 URL 参数时，分别采用 HTML 实体编码、JS 字符串转义和 URL 编码。

关联安全议题：SQL 注入与服务器加固

富文本内容最终要存入数据库，如果后端使用拼接 SQL 的方式写入，攻击者可能通过精心构造的内容实施 SQL 注入。防御 SQL 注入的几种正确写法包括：

• 参数化查询（Prepared Statement）：SELECT * FROM articles WHERE id = ?，将用户输入作为参数绑定而非拼接。
• ORM 框架：如 Sequelize、Hibernate、MyBatis 等，底层默认使用参数化。
• 输入验证：对 ID、类型等字段做严格的白名单校验。
• 最小权限原则：数据库账号只授予必要的 CRUD 权限，禁用 DROP、FILE 等高危操作。

此外，运行富文本服务的 Linux 服务器也需要基础加固：及时更新系统与依赖补丁、关闭不必要的端口和服务、配置防火墙（如 ufw 或 iptables）、使用 SSH 密钥登录并禁用 root 远程登录、启用 fail2ban 防止暴力破解、定期审计日志与文件完整性。这些措施虽然不直接针对 XSS，但能降低被攻陷后的影响范围。

总结

富文本编辑器场景下的 XSS 防御没有银弹，需要构建纵深防御体系：前端用 DOMPurify 做白名单净化提升体验，后端用同类库做二次净化确保入库安全，渲染时通过 CSP 限制脚本执行，输出时按上下文转义。同时，不要忽视 SQL 注入和服务器加固等关联环节——安全是一个整体，任何一处短板都可能导致前功尽弃。

未经允许不得转载：任鹏个人博客 » 富文本编辑器场景下的 XSS 防御方案