【问题标题】:How to ensure a .Net application is genuine?如何确保 .Net 应用程序是正版的?
【发布时间】:2010-09-22 22:35:09
【问题描述】:

在客户端-服务器应用程序中,服务器如何知道请求来自真正的应用程序而不是来自被篡改的应用程序? 我还没有开发客户端和服务器应用程序。解决方案可能是普通套接字、wcf、IIS 托管或其他。

【问题讨论】:

  • “篡改”是什么意思?
  • 我的意思是一个伪装成正版的应用程序。
  • 然后它有什么作用?到目前为止,您实际上还没有对 resource 表示 threat。那么如果第三方客户端使用你的服务器呢? 谁受伤了? 告诉我们那个场景,因为那是你真正应该分析的场景。进行安全分析时,总是从威胁开始,而不是漏洞。也就是说,不要以“此窗口已解锁”开头,而应以“有人可能试图偷走我的电视”开头。如果您从漏洞开始,那么您可能会错过一个,或者您可能会缓解错误的威胁。
  • 在您继续之前,我会执行一个正式的威胁建模过程。有一些很好的书籍和在线资源可用于学习如何构建威胁模型。
  • @Eric:该应用程序是一个游戏反黑客。我们希望阻止使用黑客工具的帐户。用户可能会尝试更改反黑客应用程序,使其显示“我还活着,用户没有使用黑客工具”。

标签: c# .net security authentication client-server


【解决方案1】:

真的没有办法。您可以要求应用程序提供的任何内容,流氓应用程序都可能进行欺骗。最终答案是您不应该信任任何客户端应用程序。您可以信任经过身份验证的用户,但客户端本身是 100% 不可信的。

为了完全说明这一点,我可以通过代理服务器运行所有流量并随意注入/删除消息。那么你就有了一个带有虚假消息的合法客户端。

现在,如果您谈论的是计划在客户端上使用的库,请确保它没有被篡改,这就是强命名程序集的用途。但这对您没有任何帮助。

【讨论】:

    【解决方案2】:

    您不能“保证”您使用的是真实客户端。计算机中真的没有“秘密”;只有更难发现的事实。可以使您的客户更有可能成为真正交易的一些因素是:

    • 身份验证。数字签名、内部散列和用户提供的数据都使您更有可能与您交谈的内容是您认为您正在交谈的内容。但是,将您的客户端程序集用作傀儡的恶意软件可能会劫持程序。即使您的代码没有可公开访问的挂钩,获得使用 SkipVerification 运行许可的恶意软件或黑客也可以反映到您的程序集中并调用私有成员。

    • 安全监控。您创建的客户端可以定期向 Windows 询问当前谁在其代码中具有内存挂钩。如果有人正在侦听或使用您的客户端,而您的客户端无法识别或服务器已识别为恶意客户端,则客户端可能会崩溃并烧毁,并且服务器知道该客户端已被入侵。这通常很难解决,但了解安全程序有助于通过快速工作以避免安全“巡逻”,或通过劫持您的客户端的挂钩进入 Windows 以询问可疑活动来帮助破坏它。

      李>
    • 行为监控。如果客户端开始发送没有意义的消息,或者没有像您期望的那样经常向您发送“仍然在这里,仍然正常”的消息,服务器可以检测到客户端有问题并进行处理作为可疑,要么完全忽略它,要么限制敏感数据。同样,知道客户端应该发送什么,或搭载客户端,可以让攻击者欺骗预期的行为。

    【讨论】:

      【解决方案3】:

      许多公司通过在两端部署数字证书(称为双向或双向身份验证)来确保客户端和服务器之间存在信任通道。几乎不可能监视或欺骗已启用相互身份验证的应用之间的任何通信。

      当然,这只会保护通道,而不是客户端应用程序本身。确保客户端完全防篡改的唯一方法是实施物理安全控制以保护正在运行的应用程序(即 ATM 和 POS 机)。

      【讨论】:

        【解决方案4】:

        我同意 Hounshell 的 cmets,因为网络上的所有数据都应被视为不受信任。但是,您可以采取一些步骤来增加所需攻击的复杂性并防止轻易篡改客户端,例如建议使用强名称。 Authenticode 证书还可以防止代码被篡改,并确保来自特定来源的软件是真实的。

        您还可以在客户端和服务器之间实现身份验证,其中身份验证基于只有用户知道的数据(未写入代码)。这规避了篡改客户端的用处,因为如果没有必要的凭据来验证服务器,攻击者就无法真正实现很多目标。为了完成攻击,他们需要拦截传输中的数据,或者在用户机器上安装一些东西(此时游戏已经结束)。

        为了保护传输中的数据免受数据窥探(中间人)攻击,您需要对数据进行加密。这可以通过客户端和服务器之间的 SSL 通信来实现,前提是执行了一些基本检查。客户端应确保证书由受信任的根 CA 签名、未过期,并且是根据与被调用者匹配的 URL 颁发的。

        【讨论】:

        • 您必须为正确的工作使用正确的安全技术。强名称绝对不是为验证客户端而设计的,因此不要为此使用它们。强名称旨在帮助用户做出关于安装在他们机器上的应用程序的信任决定,而不是帮助服务器做出关于客户端的信任决定。将安全技术用于非预期目的比根本不使用安全技术更糟糕;使用错误会产生错误的安全感,这比正确的安全感差。
        • 完全同意 - 强名称的建议是为了防止对客户端的篡改,从而促进对服务器的攻击。它绝不会使与服务器的通信更加可信,但它是提高安全性和提高攻击所需努力水平的另一个环节。
        【解决方案5】:

        您无法远程验证应用程序。

        您可以对用户进行身份验证,并且可以防止中间人攻击。但是,如果您认为经过身份验证的用户本人是敌对的并且可能会篡改应用程序,那么就没有办法阻止这种情况的发生。

        最好的办法是验证所有输入,为服务器上的操作保留关键部分,记录每个经过身份验证的用户的所有活动,并尽可能限制用户可能对您的系统造成或通过您的系统造成的损害。

        【讨论】:

          猜你喜欢
          • 2020-07-17
          • 2017-05-09
          • 2017-03-22
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多