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

Question

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

我将允许用户粘贴纯 html 字符串文本，然后以良好的格式化方式查看它。它用于粗体、下划线等。为此我将使用 .innerHTML在div .我很清楚恶意用户会把邪恶 <script>纯文本中的元素并尝试破坏我的扩展。这就是我所关心的。

我的问题:

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

---

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

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

Answer 1

在扩展中不小心使用 innerHTML 会导致几个(安全)问题，包括:

• 同源绕过(包括通用 XSS，又名 UXSS)。
• 权限升级。
• 侵犯隐私(例如引荐来源网址泄露)。

您提议的 innerHTML 使用(从不受信任的来源获取 HTML 并将其插入另一个站点的 contentEditable 元素中而不进行清理)是不安全的。理论上，脚本不应在 contentEditable 元素中执行，但存在并非如此的浏览器错误(例如 in Firefox 和 in Chrome )。
郑重声明 - 将不受信任的内容分配给 innerHTML 是不安全的，除非文档未与 View 相关联(例如，可以使用 DOMParser 或 document.implementation.createHTMLDocument 创建此类无 View 文档)。请注意，即使在此类文档中分配 innerHTML 是安全的，但将此类文档中的元素插入到具有 View 的文档中是完全不安全的。查看XSS article at OWASP有关 XSS 的一般信息。

当不受信任的内容设法在扩展的上下文中执行时，可能会发生权限升级。在内容脚本中，这仅限于跨源网络请求和一些其他扩展 API，在扩展页面中，这包括对扩展具有权限的所有扩展 API 的访问。这具有深远的影响，XSS 在扩展中并不少见。为此，Chrome enforces a default content security policy for extensions using "manifest_version": 2 .这大大降低了 XSS 在扩展中的影响，但它并非 100% 完美无缺，您不应该以 CSP 为借口不正确清理分配给 innerHTML 的数据。

(一旦尘埃落定，我可以与 CSP 旁路分享一些有影响的现实世界安全事件)

对于您的具体情况(将 DOM 树复制到另一个文档中的 contentEditable 元素)，我建议采用以下方法之一:

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

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