Chrome 扩展、内容脚本和 XSS 攻击

Question

我听说当允许eval用户输入 JS 之类的东西时，网站可能会发生危险的 XSS 攻击。我打算为我的文本扩展器扩展做一些类似的事情（输入一些文本 -> 按热键 -> 文本扩展）。

我将允许用户粘贴纯 html 字符串文本，然后以漂亮的格式查看它。它用于粗体、下划线等。为此，我将.innerHTML在div. 我很清楚恶意用户会<script>在纯文本中放入恶意元素并试图破坏我的扩展程序。这是我所关心的。

我的问题：

1. 我的扩展程序将获取此 html 数据并将其粘贴到其他网站的内容可编辑元素（如 gmail；innerHTML与内容脚本一起使用）中以进行文本扩展。XSS 也可能影响这些站点。我应该关注那些网站吗？恕我直言，他们有责任清理他们的内容。
2. 除了 chrome 同步存储服务器，我自己的扩展本身不与任何服务器通信，其中它将以纯文本形式存储这些数据。但是，我仍然innerHTML在我的options.html页面中使用相同的方式（提供交互式文本扩展游乐场）。XSS 是否也会以任何方式影响我的扩展？根据我的理解，他们（黑客）将在他们自己的电脑上使用我的扩展程序的文件副本和他们自己的浏览器。从这个意义上说，我无法辨别它们会造成什么伤害。

---

我希望了解 chrome 扩展和 XSS 工作原理的人可以提供一些启发。如果我错过了任何细节/不清楚，请告诉我。

更新：我刚刚意识到脚本元素不是通过 innerHTML 执行的，只有内联事件处理程序是。我知道使用 CSP 可以帮助我防止在我的扩展中执行内联事件处理程序。但是我的扩展程序将粘贴代码的其他网站呢？他们也不会执行内联事件处理程序 js 函数吗？

Answer 1

innerHTML在扩展中不小心使用可能会导致几个（安全）问题，包括：

• 同源绕过（包括通用 XSS，又名 UXSS）。
• 特权升级。
• 侵犯隐私（例如引荐来源泄露）。

您建议使用的innerHTML（从不受信任的来源获取HTML 并将其插入到另一个站点的contentEditable 元素中而未经过清理）是不安全的。理论上，脚本不应在contentEditable元素中执行，但存在浏览器错误，但情况并非如此（例如在 Firefox和Chrome 中）。
对于记录 - 将不受信任的内容分配给innerHTML是不安全的，除非文档不与视图相关联（例如，可以使用DOMParser或创建此类无视图文档document.implementation.createHTMLDocument）。请注意，尽管innerHTML在此类文档中分配是安全的，但将此类文档中的元素插入具有视图的文档中是完全不安全的。见OWASP 上的 XSS 文章，了解有关 XSS 的一般信息。

当不受信任的内容设法在扩展的上下文中执行时，可能会发生权限提升。在内容脚本中，这仅限于跨源网络请求和一些其他扩展 API，在扩展页面中，这包括对扩展具有权限的所有扩展 API 的访问。这会产生深远的影响，XSS 在扩展中并不少见。因此，Chrome 对使用"manifest_version": 2. 这大大减少了 XSS 在扩展中的影响，但它不是 100% 完美的，你不应该使用 CSP 作为没有正确清理你分配给的数据的借口innerHTML。

（一旦尘埃落定，我可以与 CSP 绕过分享一些有影响力的现实世界安全事件）

对于您的特定情况（将 DOM 树复制到另一个文档中的 contentEditable 元素），我建议采用以下方法之一：

• 白名单：递归枚举元素的所有子节点，如果元素是安全元素（例如“b”、“strong”、“em”、“i”等），则仅克隆该元素，如果是，则仅复制属性这是一个安全的属性。
• 黑名单：深度克隆一棵子树，并删除所有不安全元素和不安全属性（读者练习：什么是不安全元素？提示：答案并不容易，取决于属性）。

如果您没有开始的 DOM 树，请使用先前建议的方法之一（例如DOMParser）解析 HTML 。并且在选择您选择接受的元素和属性时要小心。例如，这个 safeResponse.js 文件似乎是一个好的开始（因为它删除了脚本标记和所有属性，除了一些看似安全的属性），但事实并非如此。有人可以使用该style属性使元素透明并位于整个文档的顶部，然后javascript:在该href属性中放置一个链接（链接前面的空格被浏览器剥离）。当用户单击页面中的任意位置时，脚本将在页面上下文中运行。sendResponse.js 的这个补丁修复了这个问题，结果可能对 XSS 是安全的（虽然对隐私侵犯不安全，例如可以通过style属性中的CSS 引用外部内容）。