ADO.NET 1.1 Security Checklist

From Guidance Share

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

Contents 1 SQL Injection Checks 2 Authentication 3 Authorization 4 Configuration Management 5 Sensitive Data 6 Exception Management 7 Deployment Considerations

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.