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

Question

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

javascriptgoogle-chromegoogle-chrome-extensionxss

3

我听说如果允许用户输入JS代码并使用eval函数时，网站容易受到危险的XSS攻击。我计划为我的文本扩展插件做类似的功能（输入一些文本->按快捷键->文本自动扩展）。

我将允许用户粘贴纯html字符串文本，并以漂亮的格式查看它。这是用div元素中的innerHTML属性实现的。我非常清楚，恶意用户会在纯文本中放入恶意

- Gaurang Tandon

@wOxxOm 感谢您的回复！但是 MDN 页面明确显示 const name = "<img src='x' onerror='alert(1)'>"; el.innerHTML = name; // shows the alert 可能会有安全问题。我认为这就是我担心的问题。我会更新我的问题。 - Gaurang Tandon

@wOxxOm 谢谢！很抱歉我问题重复了，但也许我只是无法理解第二个问题。“但是在扩展页面上不起作用”我已经明白了。但是如果我在另一个网站（如 Gmail）上使用内容脚本插入的 HTML，它也不会起作用吗？从技术上讲，Gmail 不是扩展页面 :/ - Gaurang Tandon

1

安全敏感的网站应该使用 CSP，完全禁止内联 js 或要求通过哈希值签名。不管怎样，我对 XSS 不是专家，希望有人能完全回答这个问题。 - wOxxOm

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rob W · Accepted Answer

在扩展程序中粗心使用innerHTML可能会导致多个（安全）问题，包括：

同源绕过（包括通用XSS，也称为UXSS）。
权限提升。
隐私侵犯（例如引荐泄漏）。

你提出的使用innerHTML（从不受信任的来源获取HTML并将其插入到另一个站点上的contentEditable元素中而没有进行消毒）是不安全的。理论上，脚本不应在contentEditable元素中执行，但有些浏览器存在此情况的错误（例如Firefox和Chrome）。顺便说一下 - 将不受信任的内容分配给innerHTML是不安全的，除非文档未与视图相关联（例如可以使用DOMParser或document.implementation.createHTMLDocument创建此类无视图文档）。请注意，即使在这样的文档中分配innerHTML是安全的，但在具有视图的文档中插入来自这样的文档的元素是完全不安全的。有关XSS的一般信息，请参见OWASP的XSS文章。

特权升级可能发生在不受信任的内容设法在扩展上下文中执行时。在内容脚本中，这仅限于跨源网络请求和一些其他扩展API，在扩展页面中，这包括访问扩展具有权限的所有扩展API。这具有深远的影响，扩展中的XSS并不罕见。因此， Chrome强制执行默认内容安全策略，使用"manifest_version": 2的扩展。这大大减少了扩展中XSS的影响，但它并非完美无缺，您不应将CSP用作不正确地处理分配给innerHTML的数据的借口。

（一旦尘埃落定，我可以分享一些具有决定性影响的真实安全事件，其中包含CSP绕过）

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

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

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