从 Chrome 扩展执行跨源请求时的 XMLHTTPRequest 漏洞？

Question

您可以使用 Chrome 扩展程序进行跨源请求。我创建了一个测试 Chrome 扩展来解决这个问题。它通过单击按钮从站点获取特定页面中的所有代码。

我想要的只是页面中的数据（只是一些文本和数字），然后将其显示在扩展程序的选项页面中。

我提取此数据的方式是遍历响应中的文档（请求的response 或responseXML 属性）。例如，我使用querySelectorAll 来获取一堆元素，然后将它们的所有textContent 属性放在一个数组中，然后我将数组上的每个元素放在扩展页面的DOM 中的<ul> 中。

最后，在我从站点请求特定页面后，我将响应文档存储在我的localStorage 中（仅存储请求的最后一页，覆盖存储的前一页）。我通过存储响应元素的outerHTML（通过document.documentElement.outerHTML）来做到这一点。然后当我刷新扩展页面时，我使用DOMParser 和parseFromString 将其转换回文档。在它被转换回文档之后，上一段中的内容再次发生（DOM 遍历和数据提取）。

任何潜在的安全问题？

MDN 是这样说的：

"处理包含 HTML 文档的 responseText 属性 如果您 使用 XMLHttpRequest 获取远程 HTML 网页的内容， responseText 属性是一个包含原始 HTML 的字符串。这可以 证明难以操纵和分析。有三个初级 分析和解析这个原始 HTML 字符串的方法：

1. 使用文章中介绍的 XMLHttpRequest.responseXML 属性 https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/HTML_in_XMLHttpRequest

2. XMLHttpRequest 中的 HTML。将内容注入文档正文 通过 fragment.body.innerHTML 分片并遍历 DOM 分段。

3. 如果你总是知道 HTML responseText 事先。您可能想要删除换行符，如果 您使用 RegExp 扫描换行符。然而，这种方法 是“最后的手段”，因为如果 HTML 代码稍有变化，该方法 可能会失败。”

我用的是第一种方法。

这个页面讨论了处理响应的危险和安全的方法（尽管这里讨论的是 responseText，而不是从 response 或 responseXML 获得的 html 文档）： https://developer.chrome.com/apps/xhr

总结：

    // 1. WARNING! Might be evaluating an evil script!
    var resp = eval("(" + xhr.responseText + ")");

    // 2. WARNING! Might be injecting a malicious script!
    document.getElementById("resp").innerHTML = xhr.responseText;

    // 3. JSON.parse does not evaluate the attacker's scripts.
    var resp = JSON.parse(xhr.responseText);

    // 4. innerText does not let the attacker inject HTML elements.
    document.getElementById("resp").innerText = xhr.responseText;

这里唯一的问题是第二个问题。我使用innerHTML 在<ul> 中创建了一个<li>，其中包含来自响应文档的数据。现在，我知道这个站点，但我想我可以将其更改为不使用 innerHTML。

Answer 1

安全 API/属性：

• textContent 或 innerText 绝对安全

• responseXML 是安全的，请参阅step 5 in XHR specification：

  对接收到的字节禁用脚本支持

• DOMParser API 同样安全。

可能不安全：

• innerHTML 不会运行 <script> 元素，请参阅 (HTML5 spec)：

  当使用innerHTML 和outerHTML 属性插入时，它们根本不执行。

  但它会在<img src="x" onerror="alert(1)"> 等事件处理程序属性中运行内联代码，尽管由于扩展页面中默认的 CSP forbidding inline code，这通常不会在扩展页面中运行，但许多作者需要放松 CSP .

  即使您没有放松默认 CSP 并希望在主文档中使用原始的外部 html，您也需要去除 <style> 和 <link> 元素，因为它们会改变主页外观，删除 @ 987654334@ 属性，<script> 元素也是如此（只是为了保持一致性）。或者将该 HTML 放在 iframe with sandbox 属性中。

  还有 Mozilla 的政策需要考虑：

  如果您的项目将接受任何形式的安全审查，那么使用 innerHTML 很可能会导致您的代码被拒绝。例如，如果您在浏览器扩展中使用 innerHTML 并将扩展提交到 addons.mozilla.org，它将不会通过自动审核过程。