Chrome 扩展、内容脚本和 XSS 攻击
Chrome extension, content script, and XSS attacks
我听说当网站允许 eval使用用户输入 JS 之类的东西时，网站可能会发生危险的 XSS 攻击。我打算为我的文本扩展程序做一些类似的事情（输入一些文本 -> 按热键 -> 文本扩展）。
我将允许用户粘贴纯 html 字符串文本，然后以格式良好的方式查看它。它用于粗体、下划线等。为此，我将在 div 中使用 .innerHTML。我很清楚恶意用户会在纯文本中放入邪恶的 <script> 元素并试图破坏我的扩展。这就是我所关心的。
我的问题：
- 我的扩展程序将获取此 html 数据并将其粘贴到其他网站的内容可编辑元素（如 gmail；使用
innerHTML 和内容脚本）以进行文本扩展。 XSS 也可能影响这些网站。我应该关注那些网站吗？恕我直言，清理内容是他们的责任。
- 我自己的扩展程序本身不与 任何 服务器通信，除了 chrome 同步存储服务器，它将以纯文本形式存储此数据。但是，我仍然在
options.html 页面中以相同的方式使用 innerHTML（以提供交互式文本扩展游乐场）。 XSS 还会以任何方式影响我的扩展吗？据我了解，他们（黑客）将在 他们自己的电脑 上使用 copy 我的扩展文件 他们自己的浏览器。从这个意义上说，我无法辨别它们会造成什么伤害。
我希望了解 chrome 扩展和 XSS 工作原理的人可以提供一些信息。如果我遗漏了任何 detail/am 不清楚的地方，请告诉我。
更新： 我刚刚意识到脚本元素不是通过 innerHTML 执行的，只有内联事件处理程序是。我知道使用 CSP 可以帮助我防止在我的扩展中执行内联事件处理程序。但是我的扩展程序将粘贴代码的其他网站呢？他们也不会执行内联事件处理程序 js 函数吗？
在扩展中不小心使用 innerHTML 会导致几个（安全）问题，包括：
- 同源绕过（包括通用XSS，又名UXSS）。
- 权限升级。
- 侵犯隐私（例如引荐来源泄露）。
您建议使用 innerHTML（从不受信任的来源获取 HTML 并将其插入另一个站点的 contentEditable 元素中而不进行清理）是不安全的。理论上，脚本不应在 contentEditable 元素中执行，但存在并非如此的浏览器错误（例如 in Firefox and in Chrome）。
郑重声明 - 将不受信任的内容分配给 innerHTML 是不安全的，除非文档与视图无关（例如，可以使用 DOMParser or document.implementation.createHTMLDocument). Note that even though assigning innerHTML in such documents is safe, it is completely unsafe to insert elements from such documents in documents with a view. See the 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", 等), 并且只复制安全属性的属性。
- 黑名单：深度克隆一个子树，并删除所有不安全元素和不安全属性（练习reader：什么是不安全元素？提示：答案并不容易，这取决于属性）。
如果您没有 DOM 树作为起点，请使用之前建议的方法之一解析 HTML（例如 DOMParser). And be careful in selecting what elements and attributes you choose to accept. For example, this safeResponse.js file seems like a good start (because it removes script tags and all attributes except for some seemingly safe attributes), but it is not. Someone can use the style attribute to make the element transparent and on top of the whole document, and then put a javascript: link in the href attribute (spaces in front of the link are stripped by the browser). When the user clicks anywhere in the page, the script runs in the page's context. This patch for sendResponse.js 修复了问题，结果对 XSS 可能是安全的（虽然对侵犯隐私不安全，例如可以通过 style 属性中的 CSS 引用外部内容）。
我听说当网站允许 eval使用用户输入 JS 之类的东西时，网站可能会发生危险的 XSS 攻击。我打算为我的文本扩展程序做一些类似的事情（输入一些文本 -> 按热键 -> 文本扩展）。
我将允许用户粘贴纯 html 字符串文本，然后以格式良好的方式查看它。它用于粗体、下划线等。为此，我将在 div 中使用 .innerHTML。我很清楚恶意用户会在纯文本中放入邪恶的 <script> 元素并试图破坏我的扩展。这就是我所关心的。
我的问题：
- 我的扩展程序将获取此 html 数据并将其粘贴到其他网站的内容可编辑元素（如 gmail；使用
innerHTML和内容脚本）以进行文本扩展。 XSS 也可能影响这些网站。我应该关注那些网站吗？恕我直言，清理内容是他们的责任。 - 我自己的扩展程序本身不与 任何 服务器通信，除了 chrome 同步存储服务器，它将以纯文本形式存储此数据。但是，我仍然在
options.html页面中以相同的方式使用innerHTML（以提供交互式文本扩展游乐场）。 XSS 还会以任何方式影响我的扩展吗？据我了解，他们（黑客）将在 他们自己的电脑 上使用 copy 我的扩展文件 他们自己的浏览器。从这个意义上说，我无法辨别它们会造成什么伤害。
我希望了解 chrome 扩展和 XSS 工作原理的人可以提供一些信息。如果我遗漏了任何 detail/am 不清楚的地方，请告诉我。
更新： 我刚刚意识到脚本元素不是通过 innerHTML 执行的，只有内联事件处理程序是。我知道使用 CSP 可以帮助我防止在我的扩展中执行内联事件处理程序。但是我的扩展程序将粘贴代码的其他网站呢？他们也不会执行内联事件处理程序 js 函数吗？
在扩展中不小心使用 innerHTML 会导致几个（安全）问题，包括：
- 同源绕过（包括通用XSS，又名UXSS）。
- 权限升级。
- 侵犯隐私（例如引荐来源泄露）。
您建议使用 innerHTML（从不受信任的来源获取 HTML 并将其插入另一个站点的 contentEditable 元素中而不进行清理）是不安全的。理论上，脚本不应在 contentEditable 元素中执行，但存在并非如此的浏览器错误（例如 in Firefox and in Chrome）。
郑重声明 - 将不受信任的内容分配给 innerHTML 是不安全的，除非文档与视图无关（例如，可以使用 DOMParser or document.implementation.createHTMLDocument). Note that even though assigning innerHTML in such documents is safe, it is completely unsafe to insert elements from such documents in documents with a view. See the 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", 等), 并且只复制安全属性的属性。
- 黑名单：深度克隆一个子树，并删除所有不安全元素和不安全属性（练习reader：什么是不安全元素？提示：答案并不容易，这取决于属性）。
如果您没有 DOM 树作为起点，请使用之前建议的方法之一解析 HTML（例如 DOMParser). And be careful in selecting what elements and attributes you choose to accept. For example, this safeResponse.js file seems like a good start (because it removes script tags and all attributes except for some seemingly safe attributes), but it is not. Someone can use the style attribute to make the element transparent and on top of the whole document, and then put a javascript: link in the href attribute (spaces in front of the link are stripped by the browser). When the user clicks anywhere in the page, the script runs in the page's context. This patch for sendResponse.js 修复了问题，结果对 XSS 可能是安全的（虽然对侵犯隐私不安全，例如可以通过 style 属性中的 CSS 引用外部内容）。