ADO.NET 1.1 Security Guidelines - Configuration Management

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Contents

Use Windows authentication

Windows authentication does not send credentials over the network. If you use Windows authentication for a Web application, in most cases, you use a service account or a process account, such as the ASP.NET process identity account, to connect to the database. Windows and SQL Server must both recognize the account you use on the database server. The account must be granted a login to SQL Server and the login needs to have associated permissions to access a database.

When you use Windows authentication, you use a trusted connection. The following code fragments show typical connection strings that use Windows authentication.

The example below uses the ADO.NET data provider for SQL Server:

SqlConnection pubsConn = new SqlConnection(
  "server=dbserver; database=pubs; Integrated Security=SSPI;");

The example below uses the ADO.NET data provider for OLE DB data sources:

OleDbConnection pubsConn = new OleDbConnection(
  "Provider=SQLOLEDB; Data Source=dbserver; Integrated Security=SSPI;" +
  "Initial Catalog=northwind");


References


Secure your connection strings

If you need to use SQL authentication, then your connection contains the user name and password. If an attacker exploits a source code disclosure vulnerability on the Web server or manages to log on to the server, the attacker can retrieve the connection strings. Similarly, anyone with a legitimate login to the server can view them. Secure connection strings using encryption.

Encrypt the Connection String

Encrypt connection strings by using DPAPI. With DPAPI encryption, you avoid encryption key management issues because the encryption key is managed by the platform and is tied to either a specific computer or a Windows user account.

Note If you are running .NET 2.0, you can use the Protected Configuration feature for encrypting the connection string. For more information on encrypting the connection string, see "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI" at http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000005.asp and "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA." at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGHT000006.asp

If you are running .NET 1.1, to use DPAPI, you must call the Win32 DPAPI functions through P/Invoke.

For details on how to build a managed wrapper class, see "How To: Create a DPAPI Library" in the "How To" section of "Microsoft patterns & practices Volume I, Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication" at http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

Store Encrypted Connection Strings Securely

The encrypted connection string can be placed in the registry or in the Web.config or Machine.config file. If you use a key beneath HKEY_LOCAL_MACHINE, apply the following ACL to the key:

Administrators: Full Control
Process Account: Read

Note The process account is determined by the process in which your data access assembly runs. This is usually the ASP.NET process or an Enterprise Services server process if your solution uses an Enterprise Services middle tier.

Alternatively you can consider using HKEY_CURRENT_USER, which provides restricted access. For more information, see the "Registry" section in Chapter 7, "Building Secure Assemblies." at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh07.asp

Note If you use the Visual Studio.NET database connection Wizards, the connection strings are stored either as a clear text property value in the Web application code-behind file or in the Web.config file. Both of these approaches should be avoided.

Although it is potentially less secure than using a restricted registry key, you may want to store the encrypted string in the Web.config for easier deployment. In this case, use a custom <appSettings> name-value pair as shown below:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <appSettings>
  <add key="connectionString" value="AQA..bIE=" />
 </appSettings>
 <system.web>
  ...
 </system.web>
</configuration>

To access the cipher text from the <appSettings> element, use the ConfigurationSettings class as shown below:

using System.Configuration;
private static string GetConnectionString()
{
 return ConfigurationSettings.AppSettings["connectionString"];
}

Do Not Use Persist Security Info='True' or 'Yes'

When you include the Persist Security Info attribute in a connection string, it causes the ConnectionString property to strip out the password from the connection string before it is returned to the user. The default setting of false (equivalent to omitting the Persist Security Info attribute) discards the information once the connection is made to the database.

References


Secure UDL files with restricted ACLs

If your application uses external universal data link (UDL) files with the ADO.NET managed data provider for OLE DB, use NTFS permissions to restrict access. Use the following restricted ACL:

Administrators: Full Control
Process Account: Read

Note UDL files are not encrypted. A more secure approach is to encrypt the connection string using DPAPI and store it in a restricted registry key.

References

Personal tools