在注入脚本和 Google Chrome 扩展代码/内容脚本之间传递消息的最安全方式是什么？答案

【问题标题】：What is the most secure way of passing messages between an injected script and Google Chrome extension code/content script?在注入脚本和 Google Chrome 扩展代码/内容脚本之间传递消息的最安全方式是什么？
【发布时间】：2016-11-13 12:39:12
【问题描述】：

定义： 请从一开始就注意，通过“注入脚本”、“扩展代码”和“内容脚本”，我将使用question 的出色第一个答案中提供的定义。

假设：如果我直接在我注入的脚本（在网络区域）中处理机密信息，不如我在内容脚本和扩展的 chrome:// 区域中处理机密信息安全代码。因此，我应该使用消息传递将机密信息从 web 区域发送到 chrome:// 区域以进行处理。

问题：我正在构建一个 Google Chrome 扩展程序，我需要在其中对从我注入的脚本派生的敏感用户数据运行一些操作。有问题的数据是机密的，我必须尽我所能确保在我对其进行操作之前，除了扩展程序的用户之外，任何人都无法看到它。在可用于在注入脚本和扩展代码/内容脚本之间传递消息的 3 种技术（定义如下）中，哪种技术最适合此目的？

我对可用于在注入脚本和扩展代码/内容脚本之间传递数据的 3 种不同技术的理解：

对于注入脚本和扩展代码（例如背景页面）之间的消息传递，可以使用chrome.runtime API。
对于注入脚本和内容脚本之间的消息传递，可以使用window.postMessage。
在注入脚本和内容脚本之间传递消息的另一种方式是通过document.dispatchEvent(CustomEvent)。

我的理解是方法 1. 不能用于注入脚本和内容脚本之间的消息传递，而方法 2. 和 3. 不能用于注入脚本和扩展代码之间的消息传递（除非消息被转发通过内容脚本到例如背景页面）。

【问题讨论】：

第一种技术是（在我看来）最好的选择，因为任何人都可以拦截来自window.postMessage（假设域匹配）和document.dispatchEvent 的消息，如果他们知道它们会发生的话。至少你可以通过传递一个扩展 id 来限制第一种技术广播到特定的扩展。
您没有提到的另一个第四个选项是使用 CORS 创建一个 XMLHttpRequest 到一个安全网站，并通过套接字或长轮询将该信息从服务器中继回扩展。

标签： javascript google-chrome security google-chrome-extension message-passing

【解决方案1】：

虽然在后台页面/内容脚本中运行的代码非常独立，但只要您将脚本注入页面上下文 - 您就身处狂野西部。任何扩展程序以及页面本身都可以访问该上下文并可以影响代码的执行方式。

例如，某些扩展程序可以覆盖chrome.runtime.sendMessage 以发送消息并记录它。这需要认真考虑 - 可能，您已经迷路了。

也就是说，方法 1 比 2/3 更难攻破 - 正如解释的那样，攻击者扩展需要直接更改页面上下文以进行干扰，而在 DOM 事件的情况下，它可以从安全的地方监听它们其内容脚本 - 事件被广播到所有内容脚本上下文。

假设您也可以对通道使用某种非对称加密技术 - 为注入的脚本提供加密密钥并将解密密钥保存在特权区域中。这可以保护通信，如果这是唯一被截获的东西，但在某些时候明文数据存在在全局上下文中 - 这可能足以让攻击者脚本提取（你必须假设，在注入脚本之前执行）。

【讨论】：

感谢您的回复@Xan。因此，可以说方法 1 的安全性依赖于这两个假设吗？ 1.) 我将代码注入其中的网页不会尝试拦截消息传递 2.) 我可以相信我的用户可以保护自己免受攻击者访问他们的计算机并偷偷安装拦截的恶意扩展程序消息传递。
我忘记了另一个假设：3.) 我正在向其中注入代码的网页不容易受到攻击者可以利用将其恶意脚本注入网页的常见网络安全漏洞的攻击。
我建议不要添加加密，因为它可能会增加一种虚假的安全感。最好专注于开发您知道不会受到损害的可信赖原语。也就是说，将您的脚本注入document_start 并保存可调用的dispatchEvent / postMessage 或（可能比以前更好，因为它是非全局的）MessageChannel 的副本。 @user5508297 但是由于您假设网页没有受到损害（“假设 3”），我看不出您要缓解什么。
@RobW 我试图说添加加密是徒劳的，那种假设情况。也许是我做得不够好。
@RobW 在document_start 注入并不是万能的，因为攻击者可能恰好在符合条件的扩展列表中更早地在document_start 注入。你永远不能假设你是先拔枪的。