HTML5 的 contenteditable 属性应该是 XSS 安全的吗？

Posted 2023-02-19

【中文标题】HTML5 的 contenteditable 属性应该是 XSS 安全的吗？

【英文标题】：Is HTML5's contenteditable attribute supposed to be XSS safe?

【发布时间】：2018-06-08 07:05:19

【问题描述】：

我已经阅读了一些相关的问题div contenteditable, XSS，但它的答案并没有突出显示 contenteditable 的 XSS 安全性。特别是关于意外（与有意的跨站点脚本相比）。当然，我知道我应该在服务器端清理用户输入。

TL.DR.：我能否确定用户不会冒着通过设置contenteditable 的页面元素引入一些外部脚本（即通过从剪贴板粘贴的数据）的风险？规范是否确保粘贴到 contenteditable 的任何标记在插入 DOM 之前都经过清理？

我注意到在我测试的两个主要浏览器 Chromium/Chrome 和 Firefox 上，似乎不可能意外地将 活动元素 插入到 contenteditable 标记中。我想象的这种附带插入的例子是：

用户从一个网页复制一个 DOM 元素选择并将它们插入到另一个站点上的 contenteditable 元素中。 用户执行（在 linux 命令行上）echo "<b onclick='alert("XSS");'>click me</b>" | xclip -t text/html -selection "clipboard" 并将其粘贴到 contenteditable。

活动元素可以是：

html 标记包含<script> html 标记包含带有内联处理程序的元素，例如 onclick="alert(\"XSS\");" 包含 javascript href 的 html 标记，例如 <a href="javascript:alert(\"XSS\")"> click me </a>

现在我的问题是，看到 contenteditable 似乎可以避免粘贴任何正常的 XSS 矢量，如果这是设计使然的话？

我读过一些specs/refs/whatever，其中既没有明确提到contenteditable 应该阻止任何活动元素 插入页面的DOM，也不允许这样做。这让我怀疑我是否应该使用 contenteditable 功能，因为我不想冒险将一些外部 javascript 插入到contenteditable 中。回答contenteditable这个XSS安全是这个问题的核心。

更新 与contenteditable 属性相比，类似的特性文档designMode 似乎是特定的（参见https://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html#designModeScriptBlocked）关于禁用javascript（因此防止XSS）。

更新 2 MDN 上引用的最新参考/规范是https://html.spec.whatwg.org/multipage/interaction.html#contenteditable 对于contenteditable 提供的不通过粘贴引入恶意 javascript 的任何保证，这奇怪的是漠不关心。

【问题讨论】：

只要你清理服务器端的输入，我不明白为什么有人在 contenteditable 中粘贴 JavaScript 甚至是一个问题。任何人都可以打开开发工具并在页面上执行任何足以引发 XSS 攻击的 JavaScript，如果服务器端没有设置为防止这种情况发生。

@DeepakKamat 我想（假设用户已登录并具有某些特权，例如删除内容），如果粘贴恶意脚本会继承此特权，我会认为这是有问题的。你打算说什么？此外，我假设 XSS 安全还涵盖了恶意脚本的用户数据（例如他的输入数据）的安全，如果可能的话，通过contenteditable 可能会 xhr/将内容发送给恶意第三方。服务器不受影响当然很好，但据我了解，攻击用户帐户/数据的 XSS 也很糟糕，因此我担心

您为什么要阅读 9 年半前的规范而不是当前规范？

@BoltClock 如果有更新的规范，我一定是错过了它，你的观点是正确的。除了我引用的规范仍然是我的搜索引擎为我提供的第一个规范。我还找到了w3c.github.io/editing/contentEditable.html。以防万一您能够指出更新的规范（如果存在）？

w3.org/TR/html5/…

【参考方案1】：

没有浏览器必须遵守的标准，因此每个浏览器都有自己的实现来处理用户输入。如果有办法，您可以确定用户会弄清楚如何做到这一点（旧版浏览器通常最容易受到影响）。清理用户的输入取决于您，无论是输入、粘贴等。（我必须为一个项目这样做，您无法依靠它“正常工作”）。

至于designMode，你链接的部分：

当要在禁用脚本的脚本执行上下文中执行脚本时，脚本必须什么都不做，也不返回任何内容（返回值无效）。

因此，例如，启用 designMode 将禁用由文档中的脚本设置的任何事件处理程序属性、事件侦听器、超时等。

这会让人觉得 designMode 让您“安全”，但请记住，规范会随着时间的推移而演变，因此如果不返回并测试所有不同的浏览器（或至少是您的用户拥有的浏览器），您永远无法确定.

【讨论】：

我已经通过document.designMode="on" 测试了“安全”，但它的行为与预期不符。 ***.com/q/47996078/1711186

Gmail 在其 html5 用户界面中使用 contenteditable，因此我无法想象任何潜在的 XSS 或 HTMLInjection davidyat.es/2016/02/16/contenteditable 问题都留给浏览器完成。对我来说，任何实现 contenteditable 的浏览器都会以粘贴内容不会造成数据泄露风险的方式实现它，这似乎是完全合乎逻辑的。没有标准的答案要么令人震惊，要么是错误的，要么是冒险的:)

我会说可怕！！但请相信我，我浏览了几个小时的文档，阅读了关于表单元素、输入事件和内容可编辑的 w3 规范，只是为了得出它是特定于实现的结论。 w3.org/TR/#w3c_all 我使用 contentEditable 开发了一个类似于 GMail 的基于 HTML 的邮件系统，但我们不能使用 designMode，因为我们希望我们自己的 JS 仍然在其中运行。 contentEditable 实际上与 或 没有什么不同 - 浏览器可能会提供很多保护措施，但它仍然取决于我们是否清理用户的输入。

我在 W3.org 上找到的唯一一个提到跨站脚本的地方是在 wiki 页面上：w3.org/Security/wiki/Cross_Site_Attacks，它将 XSS 列为页面所有者的责任，尽管这是用户生成的最后一次更新是 2009 年，所以物有所值。

不错的信息。 / 之间关于 contentEditable 的一个区别当然是粘贴到前者中，不会导致页面本身出现任何 XSS，而另一个（假设粘贴的 HTML 被呈现需要用户代理清理（​​就像firefox此时dxr.mozilla.org/mozilla-central/source/editor/libeditor/… for instace一样）。如果您将任何恶意复制的html标记粘贴到textarea中，则在加载页面的上下文中不会遇到XSS风险，就像使用contenteditable一样。