In the program, the connection string was written in each form, after the advice on this site I stuffed it in App.config and now it looks like this:

using (SqlConnection cn = new SqlConnection(ConfigurationManager.ConnectionStrings["DB"].ConnectionString))

When I recompile a program next to it, the file ApplicationName.exe.config drops out, and if I open it with a notepad, this file contains a connection string with a login password named DB and so on. . If the file is not next to the program, the program does not work, how to be? Rewrite again the connection string in each form with pens, or there are solutions, maybe encoding please tell me. After all, anyone can connect to the database using what is written there.

  • As far as I understand , you can use this advice if you temporarily rename app.config to web.config . - VladD
  • @VladD I probably still create a public variable in a static class and shove it in all parts of the code where it is needed ... Because the solution you cited is pichal longing .. - Winteriscoming
  • one
    Well yes. The meaning of writing to the config is that it can be changed between launches. If this is not necessary, a static field is probably not the worst solution. - VladD
  • 2
    Also, anyone can use the decompiler to tear out the connection string from your constant. Restrict access rights at the database level. - andreycha
  • 2
    Obfuscation. But I hint to you that you are going in the wrong direction. - andreycha

1 answer 1

As already mentioned in the comments, the connection string can in any case be obtained by an attacker if it is in the configuration file or the program code. Obfuscation can slow down this process a little, but not stop it.

There is one more minus of direct access to the database from the application - the need to provide access to the database server from the external network, with all the ensuing security problems.

However, there is a way to not expose the server to the outside and not to send a connection string to the application, but additional work is required. If it does not scare - read on.

For safe work with the database you need:

  • make database access functions in the WCF service;
  • in the service contract to determine the necessary methods that will be available to the application;
  • configure application binding to the service.
  • perform all functions of the database application only through calls to the corresponding service methods.

A lot of work, and what in return?

  • WCF service can be located on the server accessible from the external network and have direct access to the database server isolated in the internal network. That is, it will actually act as a gateway.
  • An application can only access service methods, without being able to see exactly which commands are hidden behind the service methods.
  • The application does not need a string to connect to the database. The application does not know at all that it works from the database, it works with the service.
  • With proper processing of parameters in the service methods, SQL injections are excluded, because no SQL code is transmitted, all SQL is encapsulated in the service. (yes, with the implementation curve, SQL injection can be pushed through WCF)
  • the service itself is fairly easy, from the point of view of consuming system resources, and you can simultaneously hold 2 or more services for applications of different versions that work from the same database.

And the disadvantages?

  • The need to learn new technology. WCF is quite a powerful tool and for effective use you will have to dive a little deeper into code examples on MSDN and solutions on SO, but this will be enough for a quick start.
  • Additional efforts to develop a public contract and the service itself.
  • To add new functionality in most cases, you will need to make changes to the application and service at the same time, but then, as usual, everything depends on the architecture, if the architecture is normal, then there will not be a strong headache.
  • WCF has some technological limitations, some can be circumvented, some are not, in particular, it will be difficult (but not impossible) to transfer large data sets returned by a database request.
  • Any additional layer increases the response time, the complexity of the system and the number of possible errors that will have to be caught and corrected.