15

上下文：

  • 只有当您的客户端安装了您的特定 Chrome 扩展程序时，您的 Web 服务器才必须提供独家内容。
  • 您有两种可能提供 Chrome 扩展包：
    1. 来自 Chrome 网上应用店
    2. 从您自己的服务器

问题：

  • 有很多解决方案可以让您知道已安装 Chrome 扩展程序：
    1. 在使用内容脚本加载网页时插入元素。
    2. 使用Web Requests将特定标头发送到服务器。
    3. 等等。
  • 但是似乎没有解决方案来检查与您的网页交互的 Chrome 扩展程序是否是正版的。
  • 实际上，由于任何人都可以查看和复制 Chrome 扩展程序的源代码，因此似乎无法知道当前与您的网页交互的 Chrome 扩展程序是您发布的版本还是克隆版本（并且可能有所改变）由另一个人。
  • 您似乎只能知道某些 Chrome 扩展程序正在以“预期方式”与您的网页交互，但您无法验证其真实性。

解决方案？

  • 一种解决方案可能是使用 Chrome 扩展包中包含的信息，其他任何人都无法更改或复制这些信息：
    1. 将 Chrome 扩展程序的 ID 发送到服务器？但是怎么做？
      • ID 必须由您和您的 JavaScript 代码发送，并且似乎无法使用“内部”Chrome 功能来完成。
      • 因此，如果其他人只是将相同的 ID 发送到您的服务器（某种 Chrome 扩展程序的 ID 欺骗），那么您的服务器会认为他的 Chrome 扩展程序是真实的！
    2. 使用打包应用程序时提供的私钥？但是怎么做？
      • 似乎无法以任何方式以编程方式访问或使用此密钥！
  • 另一种解决方案是使用NPAPI 插件并嵌入 GPG 等身份验证方法。但这种解决方案并不理想，主要是因为其API 文档的“警告”部分很大。
  • 还有其他解决方案吗？

笔记

这个问题试图在 Chrome 扩展的 API 中提出一个真正的安全问题：如何在与您的服务交互时检查您的 Chrome 扩展的真实性。如果有任何遗漏的可能性，或者任何误解，请随时在评论中问我。

4

2 回答 2

7

很抱歉，您提出的这个问题本质上是无法解决的，因为一个简单的问题：您不能信任客户。而且由于客户可以看到代码，因此您无法解决问题。

来自客户端的任何信息都可以通过其他方式复制。这与试图证明当用户登录到他们的帐户时实际上是用户而不是其他人发现或被给予他们的用户名和密码时，本质上是相同的问题。

互联网安全模型是围绕 2 方建立的，它们试图在没有第三方能够模仿、修改或收听对话的情况下进行通信。如果不隐藏扩展程序的源代码，客户端将与第三方无法区分（副本之间的文件 - 无法确定哪个是哪个）。

如果源代码被隐藏，那就完全是另一回事了。现在，用户或恶意方无法访问真实客户端知道的秘密，并且所有常规安全模型都适用。然而，Chrome 是否允许在扩展中隐藏源代码是值得怀疑的，因为它会产生其他安全问题。

如您所述，可以使用 NPAPI 插件隐藏一些源代码，但您已经知道它的价格。

回到目前的状态：

现在它变成了交互的含义的问题。

如果交互意味着当用户在页面上时您想知道它是您的扩展程序还是其他页面，那么您可以获得的最接近的方法是在应用程序部分下的扩展程序清单中列出您的页面，如此处所述

这将允许您在页面上询问是否通过使用安装了应用程序

    chrome.app.isInstalled

这将返回布尔值，显示您的应用程序是否已安装。该命令记录在这里

然而，这并不能真正解决问题，因为扩展程序可能已安装，但未启用，并且还有另一个扩展程序模拟与您的站点的通信。

此外，验证在客户端，因此任何使用该验证的函数都可以被覆盖以忽略此变量的结果。

但是，如果交互意味着生成 XMLHttpRequests，那么您就不走运了。由于上面讨论的源代码的可见性，无法使用当前方法完成。

但是，如果它限制您的站点对授权实体的可用性，我建议使用常规的身份验证方式：让用户登录将允许您创建会话。此会话将传播到扩展程序发出的所有请求，因此您可以解决常规客户端登录信任问题，例如帐户共享等。这些当然可以通过让用户通过他们的 Google 帐户登录来管理，大多数人都不愿意通过阻止似乎被滥用的帐户来分享和进一步缓解。

于 2012-09-19T20:36:22.587 回答
2

我建议做一些类似于 Git 使用的事情（看看http://git-scm.com/book/en/Git-Internals-Git-Objects以了解 git 如何实现它），即

创建 chrome 扩展中每个文件内容的 SHA1 值，然后重新创建之前获得的连接 SHA1 值的另一个 SHA1 值。

通过这种方式，您可以与您的服务器共享 SHA1 值并验证您的扩展，因为 SHA1 值会更改，以防万一有人更改您的任何文件。

用一些伪代码更详细地解释它：

function get_authentication_key(){

    var files = get_all_files_in_extension,
        concatenated_sha_values = '',
        authentication_key;

    for(file in files){
        concatenated_sha_values += Digest::SHA1.hexdigest(get_file_content(file));
    }

    $.ajax({
  url: 'http://example.com/getauthkey',
  type: 'post'
  async: false,
  success:function(data){
         authentication_key = data;
  }
    })

    //You may return either SHA value of concatenated values or return the concatenated SHA values
    return authentication_key;  
}

// Server side code
get('/getauthkey') do
    // One can apply several type of encryption algos on the string passed, to make it unbreakable
authentication_key = Digest::<encryption>.hexdigest($_GET['string']);
return authentication_key;
end

此方法允许您检查任何类型的文件是否已更改，可能是图像文件或视频文件或任何其他文件。很高兴知道这东西是否也能被打破。

于 2012-09-21T12:50:26.593 回答