Secure Data Access


To write secure ADO.NET code, you have to understand the security mechanisms available in the underlying data store, or database. You also need to consider the security implications of other features or components that your application may contain.

When connecting to Microsoft SQL Server, you can use Windows Authentication, also known as Integrated Security, which uses the identity of the current active Windows user rather than passing a user ID and password. Using Windows Authentication is highly recommended because user credentials are not exposed in the connection string. If you cannot use Windows Authentication to connect to SQL Server, then consider creating connection strings at run time using the SqlConnectionStringBuilder.

The credentials used for authentication need to be handled differently based on the type of application. For example, in a Windows Forms application, the user can be prompted to supply authentication information, or the user's Windows credentials can be used. However, a Web application often accesses data using credentials supplied by the application itself rather than by the user.

Once users have been authenticated, the scope of their actions depends on the permissions that have been granted to them. Always follow the principle of least privilege and grant only permissions that are absolutely necessary.

For more information, see the following resources.

Protecting Connection InformationDescribes security best practices and techniques for protecting connection information, such as using protected configuration to encrypt connection strings.
Recommendations for Data Access StrategiesProvides recommendations for accessing data and performing database operations.
Connection String BuildersDescribes how to build connection strings from user input at run time.
Overview of SQL Server SecurityDescribes the SQL Server security architecture.

Using parameterized commands helps guard against SQL injection attacks, in which an attacker "injects" a command into a SQL statement that compromises security on the server. Parameterized commands guard against a SQL injection attack by ensuring that values received from an external source are passed as values only, and not part of the Transact-SQL statement. As a result, Transact-SQL commands inserted into a value are not executed at the data source. Rather, they are evaluated solely as a parameter value. In addition to the security benefits, parameterized commands provide a convenient method for organizing values passed with a Transact-SQL statement or to a stored procedure.

For more information on using parameterized commands, see the following resources.

DataAdapter ParametersDescribes how to use parameters with a DataAdapter.
Modifying Data with Stored ProceduresDescribes how to specify parameters and obtain a return value.
Managing Permissions with Stored Procedures in SQL ServerDescribes how to use SQL Server stored procedures to encapsulate data access.

A script exploit is another form of injection that uses malicious characters inserted into a Web page. The browser does not validate the inserted characters and will process them as part of the page.

For more information, see the following resources.

Script Exploits OverviewDescribes how to guard against scripting and SQL statement exploits.

Attackers often use information from an exception, such as the name of your server, database, or table, to mount an attack on your system. Because exceptions can contain specific information about your application or data source, you can help keep your application and data source better protected by only exposing essential information to the client.

For more information, see the following resources.

Exception Handling FundamentalsDescribes the basic forms of try/catch/finally structured exception handling.
Best Practices for ExceptionsDescribes best practices for handling exceptions.

Microsoft Access and Microsoft Excel can act as a data store for an ADO.NET application when security requirements are minimal or nonexistent. Their security features are effective for deterrence, but should not be relied upon to do more than discourage meddling by uninformed users. The physical data files for Access and Excel exist on the file system, and must be accessible to all users. This makes them vulnerable to attacks that could result in theft or data loss since the files can be easily copied or altered. When robust security is required, use SQL Server or another server-based database where the physical data files are not readable from the file system.

For more information on protecting Access and Excel data, see the following resources.

Security Considerations and Guidance for Access 2007Describes security techniques for Access 2007 such encrypting files, administering passwords, converting databases to the new ACCDB and ACCDE formats, and using other security options.
Help Protect an Access database with User-Level Security (MDB)Applies to Access 2003. Provides instructions for implementing user-level security to protect data in Access 2003.
Understanding the Role of Workgroup Information Files in Access SecurityExplains the role and relationship of the workgroup information file in Access 2003 security.
Frequently Asked Questions About Microsoft Access Security for Microsoft Access versions 2.0 through 2000Downloadable version of the Microsoft Access Security FAQ.
Troubleshoot Security and ProtectionPresents solutions to common problems with security in Excel 2003.

COM+ contains its own security model that relies on Windows NT accounts and process/thread impersonation. The System.EnterpriseServices namespace provides wrappers that allow .NET applications to integrate managed code with COM+ security services through the ServicedComponent class.

For more information, see the following resource.

COM+ Role-Based Security and the .NET FrameworkDiscusses how to integrate managed code with COM+ security services.

The .NET Framework provides for interaction with unmanaged code, including COM components, COM+ services, external type libraries, and many operating system services. Working with unmanaged code involves going outside the security perimeter for managed code. Both your code and any code that calls it must have unmanaged code permission (SecurityPermission with the UnmanagedCode flag specified). Unmanaged code can introduce unintended security vulnerabilities into your application. Therefore, you should avoid interoperating with unmanaged code unless it is absolutely necessary.

For more information, see the following resources.

Interoperating with Unmanaged CodeContains topics describing how to expose COM components to the .NET Framework and how to expose .NET Framework components to COM.
Advanced COM InteroperabilityContains advanced topics such as primary interop assemblies, threading and custom marshaling.

Securing ADO.NET Applications
SQL Server Security
Recommendations for Data Access Strategies
Protecting Connection Information
Connection String Builders
ADO.NET Managed Providers and DataSet Developer Center