How to ensure the .Net application is authentic?

In a client-server application, how can a server know that a request comes from a genuine application and not from a fake copy of it? I have not developed a client or server application yet. The solution could be a simple socket, wcf, IIS, or something else.

+4
source share
5 answers

This is actually not the case. All that you could ask the application to provide, the fraudulent application can be deceiving. Ultimately, the answer is that you should not trust any client application. You can trust users if they are authenticated, but the client itself is 100% unreliable.

To fully illustrate this, I could run all traffic through a proxy server and enter / delete messages as I wanted. Then you have a legitimate client with false messages.

Now, if you are talking about a library that you plan to use on the client, make sure that it is not tampered with, which requires strong naming assemblies. But that will not help you by wire.

+7
source

You cannot “guarantee” that you are using a real client. There really are no "secrets" in computers; only facts that become more difficult to detect. Some things that can make it more likely that your client is a real deal:

  • Authentication Digital signatures, internal hashes, and user-provided data all make it more likely what you're talking to, this is what you think you're talking to. However, programs may be hijacked by malware that uses your client build as a puppet. Even if there are no public hooks for your code, part of the malicious code or hack that receives permission to run using SkipVerification may affect your assembly and cause private members.

  • Security monitoring. Clients that you create may periodically ask Windows about who currently has access to memory in their code. If someone listens to your client or uses it that your client does not recognize or that the server is identified as hostile, the client may fail and record, and the server knows that this client has been compromised. This is usually difficult to get around, but knowing the security procedure can help to compromise it, either by working quickly to avoid “patrolling” the security, or by hijacking your client hooks in Windows to ask about suspicious activity.

  • Behavior Monitoring. If the client starts sending messages that do not make sense, or does not send you the message “still here, still normal”, as often as you expect, the server may find that something is wrong with the client and treat it as suspicious , either completely ignoring it, or restricting confidential data. Again, knowing that the client should send or copy on the client, may allow an attacker to spoof the expected behavior.

+3
source

Many companies provide a trust channel between the client and server there, deploying digital certificates at each end (called mutual or two-way authentication). It is almost impossible to track or trick any connection between applications that have activated mutual authentication.

Of course, this provides only the channel, but not the client application. The only way to make sure that the client is completely protected from unauthorized access is to use physical protection that protects the running application (for example, ATMs and POS machines).

+2
source

I agree with Hounshell's comments that all data on the Internet should be considered unreliable. However, there are steps you can take to increase the complexity of the required attack and prevent the client from easily interfering, for example, with strong names, as suggested. Authenticode certificates can also provide protection against unauthorized access to the software and ensure the authenticity of the software from a specific source.

You can also implement authentication between the client and server, while authentication is based on data known only to the user (not written to the code). This circumvents the usefulness of client intervention, since an attacker cannot really achieve significant results without the necessary credentials to verify on the server. To carry out the attack, they then either needed to intercept data on the way, or install something on the user's machine (at which point the game ended anyway).

To protect data in transit from data-tracking attacks (man-in-the-middle), you need to encrypt the data. This can be achieved using SSL communication between the client and the server, provided that some basic checks are performed. The client must make sure that the certificate is signed by a trusted root certification authority, has not expired and is issued against the URL corresponding to the called.

+1
source

You cannot authenticate applications remotely.

You can authenticate users, and you can prevent man-in-the-middle attacks. But if you think that the authenticated user himself is hostile and can interfere with the application, then there is no way to stop this.

It is best to check all the inputs, reserve critical fragments for working on the server, register all activity for each authenticated user, and limit as much as possible damage that the user may cause through your system.

+1
source

All Articles