【问题标题】:Securing Chrome Native Message host保护 Chrome 原生消息主机
【发布时间】:2015-04-07 19:50:04
【问题描述】:

我正在使用 Chrome Native Messaging 开发一个应用程序,该应用程序通过 Chrome 扩展程序启动。

我的问题是:如何确保宿主应用程序与我提供的完全相同?

我需要确保扩展调用的应用程序的真实性。如果我无权读取注册表或检查是否有更改,我该如何获取它?

【问题讨论】:

    标签: google-chrome-extension chrome-native-messaging


    【解决方案1】:

    这是一个很好的问题,我猜答案是“很遗憾,你不能”。

    实现某种加密散列(例如 Chrome 用来验证扩展文件的散列)会很有趣,但这不是一个非常强大的保证。

    考虑(所有这些假设):

    • 您可以通过这种方式轻松保护注册表项/清单,但文件本身呢?
    • 假设您固定了可执行文件的哈希,然后更新它会变得很痛苦(您也必须同步更新扩展)。可以通过某种公钥签名而不是哈希来解决。
    • 假设您将可执行文件固定在清单中。它的数据文件呢?更重要的是,原生应用使用的呢?

    保护 Chrome 扩展程序/应用程序很容易,因为您依赖的唯一“库”/运行时是 Chrome 本身(并且您信任它)。一个原生应用可以依赖系统上的很多很多东西(比如已经提到的库),你如何跟踪?

    无论如何,集思广益似乎是一件有趣的事情。看看 Chrome bug tracker 是否已经有类似的东西,如果没有 - 尝试提出功能请求。也许可以尝试一些与 Chromium 相关的邮件列表来询问开发人员。

    【讨论】:

    • 您可以在构建时相对轻松地对可执行文件进行签名:计算可执行文件的哈希值,使用私钥对其进行加密,并将其存储在可执行文件本身中。扩展程序再次计算哈希值,然后将其与存储在可执行文件中的哈希值进行比较(使用公钥对其进行解密)。所以这是一个简单的签名过程,但正如您所说,您必须对本机应用程序所依赖的每个文件都执行此操作。
    • 您也可以争辩说,如果共享库被泄露,您就已经输了。而且我不确定静态链接会在多大程度上改善这种情况。
    • 关于注册表?当我安装主机应用程序时,我设置为扩展以在我定义的某个路径中调用它。但是,如果有人更改注册表并使用更改的应用程序(不是签名的应用程序)将目标指向另一个路径,则扩展程序将无法识别更改并正常执行。有什么方法可以读取注册表以确保注册表上定义的路径对应于真正加载的应用程序?
    • 不,据我所知目前没有。就像我说的那样,您可以尝试将其作为一项功能提出要求。
    • 根据 biziclop 的回答,我可以用私钥对每个文件进行签名,并将哈希值与文件一起存储。之后,进入扩展程序,我需要打开文件并验证签名。对于每个需要通过扩展名打开的文件,用户需要给予授权或确认一些弹出窗口?有没有办法让这个过程对用户透明?
    【解决方案2】:

    我知道这是一篇较旧的帖子,但我认为值得分享 Chromium 团队对我提交的错误的官方回复:https://bugs.chromium.org/p/chromium/issues/detail?id=514936

    可以修改用户计算机上的注册表或 FS 的攻击者也可以修改 chrome 二进制文件,因此此类攻击者可以通过修改 chrome 代码来禁用在 chrome 中实现的任何类型的验证。因此,chrome 必须信任 FS(以及来自本地机器的任何东西)。

    【讨论】:

      【解决方案3】:

      如果我正确理解了这个问题,解决方案可能是

      1. 在安装时向您的服务器注册您的可执行文件,并签署可执行文件并将您的注册号存储在可执行文件和服务器中
      2. 在来自扩展的每个请求(postMessage)中,另外发送一个由您的服务器提供的令牌
      3. 通过将扩展中的令牌与您的注册表号一起传递,请求服务器提供下一个令牌以向扩展发送响应
      4. 如果您是注册用户,服务器将使用令牌进行响应
      5. 使用您的注册号对其进行加密,并将其与来自扩展的令牌一起发送到扩展
      6. 扩展持有者浏览器将询问服务器它的良好响应
      7. 在扩展令牌的帮助下,服务器将识别可执行注册表号并解密可执行令牌并验证我们(服务器)为扩展令牌生成的令牌
      8. 一旦服务器确认,浏览器会将其视为响应

      重要的是,您的注册表号应该是安全的,并且客户端计算机无法从可执行文件中获取它(使用正确的签名可以实现)

      由于 chrome 停止了对 Applet 的支持,我在 chrome 中为智能卡读卡器实现了相同的功能

      唯一的漏洞是,客户端机器可以在一些工具的帮助下跟踪每个请求的发送

      如果您能够使用一些 httpOnly Cookie(客户端机器无法读取)或密码机制使您与服务器的可执行通信安全,那么您很可能是一个可以实现的安全解决方案

      【讨论】:

        猜你喜欢
        • 2015-09-02
        • 2019-02-24
        • 1970-01-01
        • 1970-01-01
        • 2014-08-04
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多