hum*_*ace 6 html javascript xss sanitization contenteditable
我已经阅读了一些相关的问题div contenteditable, XSS,但它的答案并没有强调太多关于 contenteditable 的 XSS 安全性。特别是关于意外(与故意跨站点脚本相比)。我当然知道我应该清理用户输入服务器端。
博士 :我可以确定用户不会冒险通过正在设置的页面元素引入一些外部脚本(即通过从剪贴板粘贴的数据)contenteditable?规范是否确保粘贴到 contenteditable 的任何标记在插入到 DOM 之前都经过清理?
我注意到在我测试的两个主要浏览器 Chromium/Chrome 和 Firefox 上,似乎不可能意外地将活动元素 插入contenteditable标签中。例如,我想象的这种附加插入的示例:
contenteditable另一个站点上的元素中。echo "<b onclick='alert("XSS");'>click me</b>" | xclip -t text/html -selection "clipboard"并将其粘贴到contenteditable.一个活动元素可能是这样的:
<script> onclick="alert(\"XSS\");"<a href="javascript:alert(\"XSS\")"> click me </a>现在我的问题是,如果这是设计使然,那么看到 contenteditable 似乎可以避免粘贴任何正常的 XSS 向量?
我已经阅读了一些规范/参考资料/无论它没有明确提到contenteditable应该阻止任何活动元素插入到页面的 DOM 中的任何内容,也不允许这样做。这让我怀疑是否应该使用 contenteditable 功能,因为我不想冒险将某些外部 javascript 插入到contenteditable. 回答这个 XSS 的安全性contenteditable是这个问题的核心。
更新
与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 的保证都漠不关心。
浏览器没有必须遵守的标准,因此每个浏览器都有自己的实现来处理用户输入。如果有办法,您可以确信用户会弄清楚如何做到这一点(较旧的浏览器通常是最容易受到影响的)。由你来清理用户的输入,无论是打字、粘贴等(我必须为一个项目这样做,你不可能依赖它“正常工作”)。
至于设计模式,您链接的部分:
当要在禁用脚本的脚本执行上下文中执行脚本时,该脚本必须不执行任何操作,也不返回任何内容(无效返回值)。
因此,例如,启用 designMode 将禁用文档中脚本设置的任何事件处理程序属性、事件侦听器、超时等。
这会让设计模式看起来让你“安全”,但请记住,规范随着时间的推移而发展,所以如果不回去测试所有不同的浏览器(或者至少是你的用户拥有的浏览器),你永远无法确定。