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

Microsoft Corporation

October 2005

Applies To

• ADO.NET version 2.0

Summary

This checklist presents a set of consolidated security guidelines for applications using ADO.NET version 2.0. The answers and recommendations presented in this module are designed to supplement the companion modules and additional guidance. The guidelines are organized by various categories that represent those areas where mistakes are most often made.

Contents

How To Use This Module
Input / Data Validation
SQL Injection
Configuration and Connection Strings
Authentication
Authorization
Exception Management
Sensitive Data
Code Access Security
Deployment Considerations
Companion Guidance

How to Use This Module

This checklist is a companion to "Security Guidelines: ADO.NET 2.0." Use "Security Guidelines: ADO.NET 2.0" to learn about the ADO.NET 2.0 guidelines and to learn what you should do, why you should do it, and how you can implement each guideline. Use this checklist as you develop your data access code.

You should expand and evolve this security checklist by adding data access practices that you discover during software development.

Input / Data Validation

Check	Description
	Regular expressions are used to validate input against expected patterns.
	In ASP .NET applications, ASP.NET validator controls are used to constrain and validate input.
	The application does not rely only on ASP.NET request validation.
	All untrusted input is validated inside data access methods.

SQL Injection

Check	Description
	Input data is constrained and sanitized. Data is checked for type, length, format, and range.
	Type-safe SQL parameters are used for data access.
	Where possible, dynamic queries that accept untrusted input are avoided.
	With dynamic SQL, character escaping is used to handle special input characters.
	The application login is restricted and has limited database permissions.

Configuration and Connection Strings

Check	Description
	Where possible, Windows authentication is used to avoid placing credentials in connection strings.
	Aspnet_regiis is used to encrypt credentials stored in connection strings in configuration files.
	RSA encryption is used to protect credentials stored in connection strings on Web farm servers.
	In the connection string, the PersistSecurityInfo attribute is not specified or is set to false or no.
	Where possible, connection strings are not constructed with user input.
	If user input must be used to build connection strings, the input is validated and ConnectionStringBuilder is used.
	Where possible, Universal Data Link (UDL) files for OLE DB data sources are avoided.

Authentication

Check	Description
	Where possible, Windows authentication is used to connect to the database.
	If SQL authentication is used, then strong passwords are used and enforced.
	If SQL authentication is used, then IPSec or SSL is used to protect credentials on the network.
	If SQL authentication is used, then Aspnet_regiis is used to encrypt connection strings in configuration files.
	RSA encryption is used to protect credentials stored in connection strings on Web farm servers.
	The account used to connect to the database has restricted database permissions.

Authorization

Check	Description
	Role checks or declarative or imperative principal permission checks are used to restrict calling users..
	Where appropriate, the data access library code is designed to restrict the access of calling code.
	The data access library code uses strong names to constrain partial trust callers.
	Application-specific data access code is placed in the application's bin directory.
	The application's database login is restricted in the database and can execute selected stored procedures only. The application login has no direct table access.

Exception Management

Check	Description
	Database connections are closed with using statements or in finally blocks.
	ADO.NET exceptions are not propagated to users. Only generic exception information is displayed.
	In ASP.NET applications, a generic error page is used to avoid accidentally returning detailed error information to the client.
	ADO.NET exception details are logged on the server.

Sensitive Data

Check	Description
	If sensitive data must be stored, then a strong symmetric encryption algorithm such as AES is used to encrypt it. DPAPI is used to protect symmetric encryption keys.
	Sensitive data is protected with IPSec or SSL on the network.
	Passwords are stored as irreversible hash values with added salt. Passwords are not stored in clear text or in encrypted format.

Code Access Security

Check	Description
	A custom ASP.NET policy is used to access non-SQL Server databases from partial trust ASP.NET applications.
	Extended OleDbPermission syntax is used to restrict database access on hosted servers.
	StrongNameIdentityPermission is not the only means used to restrict full trust callers.

Deployment Considerations

Check	Description
	Only required ports are opened and firewall restrictions are applied for the application.
	If credentials are stored in configuration files, they are encrypted. RSA encryption is used on Web farm servers.
	Database auditing is enabled and failed login attempts are logged.

Companion Guidance

• Security Guidelines: ADO.NET 2.0

Feedback

Provide feedback by using either a Wiki or e-mail:

• Wiki. Security Guidance Feedback page: http://channel9.msdn.com/wiki/securityguidancefeedback/.
• E-mail. Send e-mail to mailto:secguide@microsoft.com.

We are particularly interested in feedback regarding the following:

• Technical issues specific to recommendations
• Usefulness and usability issues

Technical Support

Technical support for the Microsoft products and technologies referenced in this guidance is provided by Microsoft Support Services. For product support information, please visit the Microsoft Product Support Web site at http://support.microsoft.com.

Community and Newsgroups

Community support is provided in the forums and newsgroups:

• MSDN Newsgroups: http://www.microsoft.com/communities/newsgroups/default.mspx
• ASP.NET Forums: http://forums.asp.net

To get the most benefit, find the newsgroup that corresponds to your technology or problem. For example, if you have a problem with ASP.NET security features, you would use the ASP.NET Security forum.

Contributors and Reviewers

• External Contributors and Reviewers: Anil John; Frank Heidt
• Microsoft Product Group: Don Willits, Pablo Castro, Stefan Schackow
• Microsoft IT Contributors and Reviewers: Akshay Aggarwal, Shawn Veney, Talhah Mir
• Microsoft Services and PSS Contributors and Reviewers: Adam Semel, Tom Christian, Wade Mascia
• Microsoft patterns & practices Contributors and Reviewers: Carlos Farre
• Test team: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Infosys Technologies Ltd.
• Edit team: Nelly Delgado, Microsoft Corporation
• Release Management: Sanjeev Garg, Microsoft Corporation.