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

Microsoft Corporation

Published: June 2003

Applies to:

• ADO.NET 1.1

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.

Contents

How to Use This Checklist SQL Injection Checks Authentication Authorization Configuration Management Sensitive Data Exception Management Deployment Considerations

How to Use This Checklist

This checklist is a companion to Chapter 14, "Building Secure Data Access" and Chapter 16, "Securing Your Database Server." Use it to help you build secure data access, or as a quick evaluation snapshot of the corresponding chapters.

This checklist should evolve with secure data access practices that you discover during software development.

SQL Injection Checks

Check	Description
	Input passed to data access methods that originates outside the current trust boundary is constrained. Sanitization of input is only used as a defense in depth measure.
	Stored procedures that accept parameters are used by data access code. If stored procedures are not used, type safe SQL parameters are used to construct SQL commands.
	Least-privileged accounts are used to connect to the database.

Authentication

Check	Description
	Windows authentication is used to connect to the database.
	Strong passwords are used and enforced.
	If SQL Server authentication is used, the credentials are secured over the network by using IPSec or SSL, or by installing a database server certificate.
	If SQL Server authentication is used, connection strings are encrypted by using DPAPI and are stored in a secure location.
	Application connects using a least-privileged account. The sa account or other privileged accounts that are members of the sysadmin or db_owner roles are not used for application logins.

Authorization

Check	Description
	Calling users are restricted using declarative or imperative principal permission checks (normally performed by business logic).
	Calling code is restricted using identity permission demands in scenarios where you know and want to limit the calling code.
	Application login is restricted in the database and can only execute selected stored procedures. Application's login has no direct table access.

Configuration Management

Check	Description
	Windows authentication is used to avoid credential management.
	Connection strings are encrypted and encrypted data is stored securely, for example, in a restricted registry key.
	OLE DB connection strings do not contain Persist Security Info="true" or "yes".
	UDL files are secured with restricted ACLs.

Sensitive Data

Check	Description
	Sensitive data is encrypted in the database using strong symmetric encryption (for example, 3DES).
	Symmetric encryption keys are backed up and encrypted with DPAPI and stored in a restricted registry key.
	Sensitive data is secured over the network by using SSL or IPSec.
	Passwords are not stored in custom user store databases. Password hashes are stored with salt values instead.

Exception Management

Check	Description
	ADO.NET exceptions are trapped and logged.
	Database connections and other limited resources are released in case of exception or completion of operation.
	ASP.NET is configured with a generic error page using the <customErrors> element.

Deployment Considerations

Check	Description
	Firewall restrictions ensure that only the SQL Server listening port is available on the database server.
	A method for maintaining encrypted database connection strings is defined.
	The application is configured to use a least-privileged database login.
	SQL server auditing is configured. Failed login attempts are logged at minimum.
	Data privacy and integrity over the network is provided with IPSec or SSL.