Return to PatternsAndPracticesSecurityWiki

ADO.NET 1.1 Security Checklist

Note: See online on MSDN: http://msdn.microsoft.com/library/en-us/dnnetsec/html/CL_SecuDat.asp
J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

Microsoft Corporation

June 2003

SQL Injection Checks

* 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

* 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

* 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

* 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

* 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

* 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

* 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.

---

Return to SecurityChecklists