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

时间:2022-11-27 15:17:26

The basic question
How do I know that it is my publicly accessible (client) application that is sending my service messages? How do I know that it is just not some other application that is impersonating my application?

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

Some Background
Currently we log all errors that occur on our websites via log4net and WCF to a database. This works well because the web server (accessible from the web - Partly Trusted) reports there errors to the WCF service running on the application server (inaccessible from the web - Trusted) via a trusted relationship. We therefore know that all error logs are real and we need to investigate them.

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

With our new sites we plan to make use of SilverLight to liven things up a little. The problem we are faced with is how to report errors back from the SilverLight application running on the web consumer's PC (Untrusted) to our application server (inaccessible from the web - Trusted).

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

We can solve the inaccessibility problem of the application server by making the client communicate via a service facade on the web server, so that is no worry. The problem occurs when we need to be sure that the application sending the messages really is our application and not just an impersonator.

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

Some Thoughts
The code will be written in C# and be running in a SilverLight application that runs locally on the client PC, so we cannot be guaranteed that it will not be decompiled and used to send fake messages to our service.

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

The above means that we cannot make use of conventional symmetric encryption because we can't store our private key in the application (it can be decompiled). Similarly we can't use asymmetric encryption since it could just be impersonated (the attacker could just sign messages with the stored public key and send them - the messages would look real)

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

In the case of this application there is no user authentication, so we cannot use that to provide us with trust.

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

Yes, I know this is rather bizzare with the error logs being better protected than the data the application displays, but it is the case :)

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

Any thoughts or help would be greatly appreciated!

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

3 个解决方案

#1


Impossible.

You can authenticate users, but not the application.

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

Let's say you decide to digitally sign the application. This signature is then read at runtime by your client application checking its own executable binaries against this signature. There is nothing that prevents the adversary from simply removing this check from your application.

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

Even if you make it close to impossible to reverse engineer your application, the adversary could always look at the communication channel and write an imposter that looks indistinguishable from your client to your server.

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

The only thing you can do is validate the actions on the server against a user identity.

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

#2


Presumably, your server is creating the web page that the Silverlight application sits in. You could create a short-lived temporary "key" that only that web page contains. When the Silverlight app starts up, it reads this key and uses it. Because the server itself has a constantly changing, very short list of allowed keys, you can be more sure that only your app is accessing your services.

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

#3


The best advice for you in this matter is to hire a security expert to help you. This is not a unique or unusual problem -- consider any game (like WoW for example) that is attempting to determine if it is speaking to a true client or a fraudulent client. Even with a massive amount of effort (look up Blizzard Warden, I'm not going to link it here), they still have issues. The problem boils down to exactly how much time and effort your attacker is going to invest in thwarting your attempts to make thing hard on him. Just be sure to validate everything on the server-side. :)

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

#1


Impossible.

You can authenticate users, but not the application.

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

Let's say you decide to digitally sign the application. This signature is then read at runtime by your client application checking its own executable binaries against this signature. There is nothing that prevents the adversary from simply removing this check from your application.

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

Even if you make it close to impossible to reverse engineer your application, the adversary could always look at the communication channel and write an imposter that looks indistinguishable from your client to your server.

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

The only thing you can do is validate the actions on the server against a user identity.

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

#2


Presumably, your server is creating the web page that the Silverlight application sits in. You could create a short-lived temporary "key" that only that web page contains. When the Silverlight app starts up, it reads this key and uses it. Because the server itself has a constantly changing, very short list of allowed keys, you can be more sure that only your app is accessing your services.

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

#3


The best advice for you in this matter is to hire a security expert to help you. This is not a unique or unusual problem -- consider any game (like WoW for example) that is attempting to determine if it is speaking to a true client or a fraudulent client. Even with a massive amount of effort (look up Blizzard Warden, I'm not going to link it here), they still have issues. The problem boils down to exactly how much time and effort your attacker is going to invest in thwarting your attempts to make thing hard on him. Just be sure to validate everything on the server-side. :)

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