如何验证客户端应用程序以信任从它发送的消息

Posted 2023-03-08

【中文标题】如何验证客户端应用程序以信任从它发送的消息

【英文标题】：How to authenticate client application for trust of messages sent from it

【发布时间】：2010-11-11 10:47:26

【问题描述】：

基本问题 我如何知道发送我的服务消息的是我的可公开访问（客户端）应用程序？我怎么知道冒充我的应用程序的不是其他应用程序？

一些背景 目前，我们通过 log4net 和 WCF 将我们网站上发生的所有错误记录到数据库中。这很有效，因为 Web 服务器（可从 Web 访问 - 部分受信任）通过受信任的关系向应用程序服务器上运行的 WCF 服务报告错误（无法从 Web 访问 - 受信任）。因此，我们知道所有错误日志都是真实的，我们需要对其进行调查。

通过我们的新网站，我们计划利用 SilverLight 让事情变得活跃一点。我们面临的问题是如何将错误从运行在 Web 消费者 PC（不受信任）上的 SilverLight 应用程序报告回我们的应用程序服务器（无法从 Web 访问 - 受信任）。

我们可以通过让客户端通过Web服务器上的服务门面进行通信来解决应用服务器的不可访问性问题，这样就不用担心了。当我们需要确保发送消息的应用程序确实是我们的应用程序而不仅仅是冒充者时，就会出现问题。

一些想法 代码将用 C# 编写并在客户端 PC 上本地运行的 SilverLight 应用程序中运行，因此我们不能保证它不会被反编译并用于向我们的服务发送虚假消息。

以上意味着我们不能使用传统的对称加密，因为我们不能将我们的私钥存储在应用程序中（它可以被反编译）。同样，我们不能使用非对称加密，因为它可能只是被冒充（攻击者可以使用存储的公钥签署消息并发送它们 - 消息看起来是真实的）

在这个应用程序的情况下，没有用户身份验证，所以我们不能用它来为我们提供信任。

是的，我知道这很奇怪，因为错误日志比应用程序显示的数据受到更好的保护，但事实就是这样 :)

任何想法或帮助将不胜感激！

【参考方案1】：

不可能。

您可以验证用户，但不能验证应用程序。

假设您决定对应用程序进行数字签名。然后，您的客户端应用程序会在运行时读取此签名，并根据此签名检查其自己的可执行二进制文件。没有什么可以阻止攻击者简单地从您的应用程序中删除此检查。

即使您几乎不可能对您的应用程序进行逆向工程，攻击者也可以随时查看通信渠道并编写一个从您的客户端到您的服务器看起来无法区分的冒名顶替者。

您唯一能做的就是根据用户身份验证服务器上的操作。

【讨论】：

这几乎是我达到的目的，但这似乎是一个常见的软件问题。我希望能得到更多的想法，这些想法可能会让我走上正确（或更好）的道路。

在技术方面说“不可能”是一个非常糟糕的主意。一般来说，在别人说“不可能”的时候，已经有人这样做了……

我不认为这是技术问题。这是信息不完整的问题。服务器从不受信任的来源获取指令。只有从受信任的渠道提供信息，才能信任此来源。

这就是技术争论的重点。现有技术的新用途，或新技术可用于创建可信渠道。

【参考方案2】：

大概，您的服务器正在创建 Silverlight 应用程序所在的网页。您可以创建一个只有该网页包含的短期临时“密钥”。当 Silverlight 应用程序启动时，它会读取并使用此密钥。因为服务器本身有一个不断变化的、非常短的允许密钥列表，所以您可以更加确定只有您的应用在访问您的服务。

【讨论】：

服务器如何知道哪个客户端可以安全地提供密钥？

他已经通过创建一个嵌入在 Web 服务器托管的网页中的 Silverlight 应用程序来确定这一点。任何可以访问该页面的浏览器都是有效的客户端。

我喜欢 John 的这个想法，但测试它看起来像传递给 SilverLight 应用程序的参数是以纯文本形式传递的。什么会阻止某人阻止 SilverLight 应用程序的加载，然后使用一次性的短期密钥来访问服务？

您无法达到 100% 安全的系统（无论如何这是一个普遍的安全问题）。但是，您可以使关键点更难破解。如果您认为有人加载页面并阅读您的密钥然后使用不同的应用程序调用事物的可能性足够高，那么您花钱来避免这个问题。假设您需要，您可以采用另一种方法，即每隔 X 分钟或几小时自动更新 SilverLight 应用程序本身。这样一来，在带有新代码的新应用程序到位之前，黑客就没有足够的时间破解该应用程序。

【参考方案3】：

在这件事上对您的最佳建议是聘请安全专家来帮助您。这不是一个独特或不寻常的问题——考虑任何试图确定它是在与真实客户还是欺诈客户交谈的游戏（例如 WoW）。即使付出了巨大的努力（查看暴雪守望者，我不会在这里链接它），他们仍然有问题。问题归结为您的攻击者将投入多少时间和精力来阻止您对他施加压力的企图。只要确保验证服务器端的所有内容。 :)