【问题标题】:Automatic updates - what is 'adequate' security?自动更新 - 什么是“足够的”安全性?
【发布时间】:2010-10-09 09:06:47
【问题描述】:

有几个问题(C#Java)涉及如何实现自动更新。提供自动更新最初似乎很容易,而且似乎没有充分的理由不为大多数软件提供自动更新。

但是,似乎没有一个涵盖自动更新的安全方面。

  • 现在自动更新有多安全?
  • 它们应该有多安全?
  • 它们有多安全?

我的主要问题是,从所有意图和目的来看,互联网都是一个狂野的西部,人们无法对他们收到的任何数据做出任何假设。通过互联网自动更新似乎存在固有风险。

公司计算机被感染,欺骗 DNS(只有一小部分获胜),并使其他公司计算机相信通用应用程序的更新服务器在其他地方,他们下载“新”应用程序并被感染.

作为开发人员,可能存在哪些攻击,我应该采取哪些措施来保护我的客户免受滥用?

-亚当

【问题讨论】:

    标签: security deployment auto-update


    【解决方案1】:

    通过正确使用加密技术,您的更新会非常安全。使用 SSL 保护您从中分发更新的站点。使用 GPG/PGP 或其他方式对所有更新进行签名,让您的客户在应用更新之前验证签名。采取措施确保您的服务器和密钥非常安全。

    足够,是非常主观的。对于网络游戏来说足够了,对于我们的核导弹的安全系统来说可能完全不够。如果有人设法破坏了您的安全,您必须确定可能造成多大的潜在损害。

    【讨论】:

      【解决方案2】:

      最明显的攻击是攻击者通过他的“邪恶”更新服务器提供更改的二进制文件。因此,您应该确保可以使用数字签名验证下载的数据是否来自您。

      为了确保安全,显然您应该避免分发签名密钥。因此,您可以实现RSA message signing 的一些变体

      【讨论】:

        【解决方案3】:

        通过 SSL 连接到您的更新服务器就足够了,前提是您的客户端在获得无效证书时会拒绝连接,并且您的服务器需要协商合理的连接安全级别(客户端也支持)。

        但实际上,您所做的几乎任何事情都至少与您的用户首次安装您的软件的路径一样安全。如果您的用户最初通过纯 http 下载您的安装程序,那么开始保护更新内容为时已晚。

        这在某种程度上也是如此,即使他们通过 https 或数字签名获取您的初始软件 - 因为大多数用户可以很容易地被说服在他们看到的几乎所有安全警告上单击“确定”。

        【讨论】:

          【解决方案4】:

          似乎没有充分的理由不为大多数软件提供自动更新。

          有充分的理由不强制更新。

          1. 错误修复可能会破坏代码
          2. 用户可能不想冒险破坏依赖旧功能的生产系统

          【讨论】:

          猜你喜欢
          • 2015-06-06
          • 1970-01-01
          • 2012-07-02
          • 1970-01-01
          • 1970-01-01
          • 2011-05-17
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多