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

时间:2017-01-02 03:46:34

标签: javascript google-chrome google-chrome-extension xss

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

我将允许用户粘贴一个普通的html字符串文本,然后以一种很好的格式化方式查看它。它用于粗体,下划线等。为此,我将在.innerHTML中使用div。我非常清楚恶意用户会将纯<script>个元素放在纯文本中,并试图破坏我的扩展名。这就是我所关注的。

我的问题:

  1. 我的扩展程序会将此html数据粘贴到其他网站的内容可编辑元素(如gmail;使用innerHTML和内容脚本)中进行文本扩展。 XSS也可能会影响这些网站。我应该关注那些网站吗? Imho,他们有责任对其内容进行消毒。
  2. 我自己的扩展程序本身不与任何服务器通信,但chrome同步存储服务器除外,它将以纯文本格式存储此数据。但是,我仍然在我的innerHTML页面中以相同的方式使用options.html(以提供交互式文本扩展操场)。 XSS能否以任何方式影响我的扩展?根据我的理解,他们(黑客)将使用他们自己的浏览器他们自己的电脑上使用我的扩展文件的副本。在这个意义上,我无法看出它们可能造成的伤害。
  3. 我希望知道Chrome扩展和XSS工作方式的人可以提供一些帮助。如果我错过任何细节/不清楚,请告诉我。

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

1 个答案:

答案 0 :(得分:3)

在扩展程序中不小心使用innerHTML会导致多个(安全)问题,包括:

  • 相同的原始绕道(包括通用XSS,又名UXSS)。
  • 权限提升。
  • 隐私权违规(例如推荐人泄露)。

您建议使用innerHTML(从不受信任的来源获取HTML并将其插入另一个站点上的contentEditable元素而不进行清理)是不安全的。从理论上讲,脚本不应该在 contentEditable 元素中执行,但是存在浏览器错误,而不是这种情况(例如in Firefoxin Chrome)。 对于记录 - 将不受信任的内容分配给innerHTML是不安全的,除非文档未与视图相关联(例如,可以使用DOMParserdocument.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元素),我建议采用以下方法之一:

  • 白名单:以递归方式枚举元素的所有子节点,并且只有元素才能克隆元素(例如&#34; b&#34;,&#34; strong&#34;,&#34; em& #34;,&#34; i&#34;等),只有在属性安全的情况下才复制该属性。
  • 黑名单:深度克隆一个子树,删除所有不安全的元素和不安全的属性(读者练习:什么是不安全的元素?提示:答案不容易,这取决于属性)。

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