Securing Database Connection Strings

Paladion
By Paladion

September 15, 2004

In today's systems, we check applications for vulnerabilities, write safer code and encrypt data communication; but we often overlook the database connection string. A connection string specifies the parameters for an application to connect to a database: it holds a lot of critical information including the username and password for accessing the database. Applications traditionally pass and store connection strings in plain text. An adversary could get this data if he has access to the machine. So what is the solution to this problem?

In today's systems, we check applications for vulnerabilities, write safer code and encrypt data communication; but we often overlook the database connection string. A connection string specifies the parameters for an application to connect to a database: it holds a lot of critical information including the username and password for accessing the database. Applications traditionally pass and store connection strings in plain text. An adversary could get this data if he has access to the machine. So what is the solution to this problem?

ConnectionsOne easy method is to hide the connection string in obscure locations. Let's call this the Data Hiding Method. The common locations for hiding connection strings include the application source code, configuration files, the registry or files like global.asa in ASP. When the connection needs to be made, the connection string is read from the location known only to the developer. This minimizes the chance discovery of the string if someone gets hold of the source code. However the string is still stored in plain text and can easily be located by a persistent attacker. For example, an attacker can locate the hidden data with tools that monitor application activity like regmon and filemon from SysInternals. Though not completely foolproof, there is a degree of security that data hiding provides.

Operating systems can control access to files using permissions. Let us call this method of protection the Access Control Method. This method relies on controlling access to the location where the data is hidden. Control can be identity based (e.g. access allowed to specific users or machines) or knowledge based (e.g. access allowed on knowing a password or key). Thus when running an application, the connection string is accessible only to authorized accounts. This is better than just hiding the data. However there are drawbacks. For instance, if access control depends on the identity of the user, it will not work for applications running as anonymous user such as ASP.NET applications. Also, it won't work for applications running under multiple identities. In knowledge based access control the problem shifts from protecting the actual data to protecting the secret key used to access it. This is definitely an improvement over Data Hiding, but it's still not perfect.

If we could remove the drawbacks of both and make it self-managed, it would be still better. An answer is the Encryption Method. In this technique the connection string is encrypted and stored in a file or registry. The application decrypts the data before using it. Hiding or controlling access to the connection information is not needed any more because it cannot be used even if it is found, without the decryption key. This technique depends on the successful protection of the cryptographic key. Again the same techniques of data hiding and access control apply here. For Windows applications, one could use Microsoft Data Protection API (DPAPI) for encrypting and decrypting the data. The advantage of using DPAPI is that the key handling is the responsibility of the OS, not the user.

We recommend that designers use the Encryption method for protecting connection strings in their applications. This will ensure that the critical database connection string is adequately protected from attackers even if they have local access to the application server.


Tags: Technical

About

Paladion