Protect the connection string in a . NET Winforms application?

Asked

Viewed 2,054 times

3

I have an app .NET Windows Forms connecting to a server SQL Server directly, without the use of an intermediate layer as a Webservice or Webapi, through SqlConnection. This application is installed on the clients' computer while the server is available over the internet.

What is the best way, without changing the entire application, to prevent the connection string (Connection string) is captured through a Sniffer type the Wireshark running on the same network?

3 answers

2

According to this article in English, the SQL Server connection component will already encrypt the important parts of the connection string during connection, such as password and username... unless you use ODBC.

Following some links from this article, I found this article from MSDN: Encrypting connections with SQL Server that shows how to force the use of SSL to encrypt ALL data traffic between client and SQL Server.

  • Even if the user and password are hidden, any return that the bank sends to the application can be captured by Sniffer. If you do a "select * from user" will be shown all the data of all users in the received traffic even if the application does not display any of this data.

  • Just use SSL, and problem solved.

  • Out work to implement after just use SSLstrip to capture.

  • What Maicon said, that "all data of all users in traffic" is natural, even with webservices it happens. The idea is to prevent someone getting authentication to manipulate the data outside of your application. I will try to implement the option Encrypt=yes of connectionString, then if I succeed I will come back here to mark the answer.

  • SQL Server does not use HTTPS, but yes TSL/SSL, so Sslstrip should not be able to read SQL Server transmissions, as the second works on HTTPS.

  • @Miguelangelo Error of mine regarding capturing the encrypted connection of SQL Server, had taken into account only you have mentioned the use of SSL. At least so far né huaehaeuhea and won +1 :)

Show 1 more comment

1


I found that older SQL versions, prior to 2005 (specifically 2000) do not work with the parameter encrypt=yes in the connection string (Connection string). I tried on another more recent server and got the error:

Provider: SSL provider, error: 0 - The certification chain was issued by an unreliable authority.

Then I found another parameter trustservercertificate=true which I added to my connection string and it worked. This parameter allows my client to accept a certificate issued by the server.

In tests I did with Wireshark I was unable to intercept neither the connection string nor the SQL statements nor the return data. The data now travels encrypted.

So the solution I found was to include this chunk at the end of the connection string:

encrypt=yes;trustservercertificate=true;

1

The correct thing would be for you not to have this connection to cliente -> banco and yes cliente -> webService (com autenticação) -> banco. As much as you try to do some kind of Find/Encrypt string, all traffic done between the client and the bank can be captured by Sniffer. Any select can be captured even if your application does not show this data they will come in traffic and can be captured without difficulty.

Behold:

inserir a descrição da imagem aqui

Even if you try to implement a secure connection, this can be circumvented by sslstrip. It is easier to create a Webservice and thereby leave the communication with the customer’s isolated bank.

  • If you can prevent direct access to the bank from being barred, that is to say, prevent authentication information from being accessible, you already solve it. Because even with webservices or webapis, information about data types and fields can be intercepted.

  • Nor can I consider that it is easier to implement with webservice a considerable application that is already in production.

  • @iuristona Really, considering that it is already in production it is difficult to have all this rework. As for the Webservices being intercepted the difference is that in Webservice you can have a control of who ordered, how to send, can handle the data before sending and obstructs any possibility of the user knowing the location of the database.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.