Chrome扩展程序，内容脚本和XSS攻击

Question

我听说一个网站可能会出现危险的XSS攻击，例如eval允许用户输入JS。我打算为我的文本扩展扩展名（类型一些文本 - >按热键 - >文本扩展）做类似的事情。

我将允许用户粘贴一个普通的html字符串文本，然后以不错的格式化方式查看它。它旨在用于粗体，下划线等。为此，我将在div中使用.innerHTML。我非常了解，恶意用户会将邪恶的<script>元素置于纯文本中，并试图破坏我的扩展。这是我所关心的。

我的问题：

1. 我的扩展将以此为HTML数据，并将其粘贴到其他网站内容编辑的要素（如Gmail，利用innerHTML与内容脚本）文本增加。 XSS也可能会影响这些网站。我应该关心这些网站吗？ Imho，他们有责任清理他们的内容。
2. 我自己的扩展本身不会与任何服务器通信，除了铬同步存储服务器，其中它将以纯文本形式存储此数据。但是，我仍然在我的options.html页面中使用innerHTML（提供交互式文本扩展操场）。 XSS也会以任何方式影响我的扩展吗？根据我的理解，他们（黑客）将使用拷贝的我的扩展文件自己的电脑与自己的浏览器。我无法分辨出他们在这个意义上可能造成的伤害。

---

我希望有人有两个镀铬的扩展和XSS如何工作可以抛出一些轻知识。如果我错过了任何细节/不清楚，请告诉我。

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

Answer 1

使用不慎的innerHTML会导致几个（安全）问题，包括：

• 同一产地旁路（包括通用XSS，又名UXSS）。
• 特权升级。
• 隐私违规（例如引荐泄漏）。

您的建议使用innerHTML（从不受信任的来源获取HTML并将其插入另一个没有消毒的网站的contentEditable元素中）是不安全的。从理论上讲，脚本不应该在contentEditable元素中执行，但如果不是这种情况，则会出现浏览器错误（例如in Firefox和in Chrome）。
对于记录 - 将不可信内容分配给innerHTML是不安全的，除非文档未与视图关联（例如，这种无视图文档可以使用DOMParser或document.implementation.createHTMLDocument）创建。请注意，尽管在这些文档中分配innerHTML是安全的，但是完全不安全要将这些文档中的元素插入到具有视图的文档中。有关XSS的一般信息，请参阅XSS article at OWASP。

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

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

对于您的具体情况（复制DOM树到CONTENTEDITABLE元素在另一个文件），我建议的一个以下方法：

• 白名单：递归枚举元素的所有子节点，如果它是一个安全元件（例如，“b”，“强”，“EM”只克隆元素，“我”，等等），并且只有在属性是安全属性时才复制该属性。
• 黑名单：深入克隆一棵树，并删除所有不安全的元素和不安全的属性（练习读者：什么是不安全的元素？提示：答案不容易，它取决于属性）。

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