如何validation客户端应用程序是否信任从其发送的消息

基本问题
我怎么知道这是我的公共可访问(客户端)应用程序发送我的服务消息? 我如何知道冒充我的应用程序的其他应用程序并不是真的?

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

通过我们的新网站,我们计划利用SilverLight来实现一些目标。 我们面临的问题是如何将在Web使用者PC(不受信任)上运行的SilverLight应用程序的错误报告回我们的应用程序服务器(无法访问Web – 受信任)。

我们可以通过Web服务器上的服务外观进行客户端通信来解决应用服务器的不可访问性问题,所以不用担心。 当我们需要确保发送消息的应用程序确实是我们的应用程序而不仅仅是模仿者时,就会出现问题。

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

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

在此应用程序的情况下,没有用户身份validation,因此我们不能使用它来为我们提供信任。

是的,我知道这是错误的,错误日志比应用程序显示的数据更好地受到保护,但事实是这样:)

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

不可能。

您可以validation用户,但不能validation应用程序。

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

即使您几乎不可能对应用程序进行逆向工程,对手也可以始终查看通信通道并编写一个与客户端无法区分的冒名顶替服务器。

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

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

在这个问题上,最好的建议是聘请一位安全专家来帮助您。 这不是一个独特或不寻常的问题 – 考虑任何试图确定它是否与真实客户或欺诈客户交谈的游戏(例如WoW)。 即使付出了巨大的努力(查看暴雪守望者,我不会在这里链接它),他们仍然有问题。 问题归结为攻击者将花费多少时间和精力来阻止你试图让他努力的事情。 只需确保在服务器端validation所有内容。 🙂