ADO.NET 2.0 Security Guidelines - Configuration and Connection Strings

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Chaitanya Bijwe


Contents

Avoid Credentials in Connection Strings

Where possible, use Windows authentication to connect to the database. Connection strings that use Windows authentication do not contain credentials because the application's process or thread identity is used to connect.


To use Windows authentication, you need to use an appropriately formatted connection string, the precise syntax of which varies depending on the provider you are using.

  • With SqlClient, use Integrated Security=true.
  • With SqlClient: OleDb, use Integrated Security=SSPI.
  • With Odbc, use Trusted_Connection=yes.
  • With OracleClient, use Integrated Security=yes.


Additional benefits from using Windows authentication to connect to the database include:

  • Credentials are not transmitted over the network to the database.
  • The use of strong passwords and other password policies, such as password expiration, can be enforced through Microsoft Active Directory® directory service security policy.
  • Active Directory is the central point of account maintenance. There are no separate accounts in the database.


Store Encrypted Connection Strings in Configuration Files

To avoid storing connection strings in your code, you can store them in the Web.config file for an ASP.NET application and in the App.config file for a Windows application. You store connection strings in the <connectionStrings> section of the configuration file.


Connection strings are stored as key/value pairs, where the name can be used to look up the value stored in the connectionString attribute at run time. The following example of a configuration file shows a connection string named MyDatabaseConnection that refers to a connection string which connects to a local instance of SQL Server.

<connectionStrings>
 <add name="MyDatabaseConnection"
      connectionString="Persist Security Info=False;Integrated
                        Security=SSPI;database=Northwind;server=(local);"
      providerName="System.Data.SqlClient" />
</connectionStrings>


Use the following code to retrieve the connection string from the configuration file.

using System.Configuration;
...
string connectionString =
 ConfigurationManager.ConnectionStrings["MyDatabaseConnection"].ConnectionString;


For additional protection, use protected configuration and either DPAPI or RSA encryption to encrypt the <connectionStrings> section. To do so, you use the Aspnet_regiis utility.

Note Use RSA in Web farms because you can easily export and import RSA keys across servers. Encrypting connection strings with Aspnet_regiis does not change the code required to access the string because the decryption occurs automatically. Encrypting a connection string is particularly important if you use SQL authentication and you have credentials in the connection string. If you do not have credentials in the connection string, compare the additional security benefits of keeping the database name and server name secret with the additional deployment complexity that encrypting the configuration file introduces.


For more information about how to use DPAPI and RSA encryption to encrypt configuration file elements, see:


Do Not Use Persist Security Info="true" or "yes"

If you must supply a user ID and password when making a connection, you should make sure that this information is discarded after it is used to open the connection. This occurs when Persist Security Info is set to "false" or "no".


Setting the Persist Security Info keyword to "true" or "yes" in a connection string allows security-sensitive information, including the user ID and password; to be obtained from the connection after the connection has been opened.


Keeping Persist Security Info as "false" helps to make sure that the untrusted source does not have access to the security-sensitive information for your connection and also helps to make sure that no security-sensitive information is saved to disk with your connection string information. Persist Security Info is set to "false" by default.


Avoid Connection Strings Constructed With User Input

Where possible, avoid connection strings constructed with user input. If you must build a connection string dynamically with information from an external source—such as using a user-supplied data source or server name or a user ID and password—make sure that you validate any input from the source. Then, use one of the connection string builder classes that derive from System.Data.Common.DbConnectionStringBuilder class, as shown in the following code example. The code example shows the System.Data.SqlClient.SqlConnectionStringBuilder class for use with the SQL Server managed data provider.

using System.Data.SqlClient;
...
public string BuildConnectionString(string serverName, string uid, string pwd)
{
 // Validate input parameters
 ...

 // Build Connection string
 SqlConnectionStringBuilder connectionStringBuilder = new 
                                             SqlConnectionStringBuilder();
 connectionStringBuilder.DataSource = serverName;
 connectionStringBuilder.UserID = uid;
 connectionStringBuilder.Password = pwd;
 return connectionStringBuilder.ConnectionString;
}


The ConnectionStringBuilder class is new to ADO.NET 2.0. Use the ConnectionStringBuilder class to allow compile-time checks and to reduce the risk of connection string injection attacks. You should use this class to build your connection string, rather than passing simple strings to the Connection objects.


DbConnectionStringBuilder class provides the base class from which strongly typed connection string builders derive. These include SqlConnectionStringBuilder, OracleConnectionStringBuilder, OdbcConnectionStringBuilder, and OleDbConnectionStringBuilder.


Avoid Universal Data Link (UDL) Files Where Possible

You should avoid supplying connection information for an OleDbConnection in a Universal Data Link (UDL) file. UDL files are not encrypted and expose connection string information in clear text. Because a UDL file is an external file-based resource to your application, it cannot be secured by using the .NET Framework.


If you must use UDL files, restrict access to them by configuring an access control list (ACL) that restricts access to the account under which your application runs.

Personal tools