Tuesday, October 17, 2006

Security Guidelines- checklist for developers

The following is a quick checklist for improving and enhancing security for your ASP.NET 2.0 applications. I use them like a check list at the design and architecture stage of development. But there is a lot of benefit in using them for testing and as an implementation reference guide when you can.

Input/Data Validation
• Do not rely on ASP.NET request validation
• Validate input for length, range, format, and type
• Validate input from all sources like QueryString, cookies, and HTML controls
• Do not rely on client-side validation
• Avoid user-supplied file name and path input
• Do not echo untrusted input
• If you need to write out untrusted data, encode the output
Authentication
Forms Authentication

• Use membership providers instead of custom authentication
• Use SSL to protect credentials and authentication cookies
• If you cannot use SSL, consider reducing session lifetime
• Validate user login information
• Do not store passwords directly in the user store
• Enforce strong passwords
• Protect access to your credential store
• Do not persist authentication cookies
• Restrict authentication tickets to HTTPS connections
• Consider partitioning your site to restricted areas and public areas
• Use unique cookie names and paths
Windows Authentication
• Choose Windows authentication when you can
• Enforce strong password policies
Authorization
• Use URL authorization for page and directory access control
• Configure ACLs on your Web site files
• Use ASP.NET role manager for roles authorization
• If your role lookup is expensive, consider role caching
• Protect your authorization cookie
Code Access Security
• Consider code access security for partial trust applications
• Choose a trust level that does not exceed your application's requirements
• Create a custom trust policy if your application needs additional permissions
• Use Medium trust in shared hosting environments
Data Access
• Encrypt your connection strings
• Use least-privileged accounts for database access
• Use Windows authentication where possible
• If you use Windows authentication, use a trusted service account
• If you cannot use a domain account, consider mirrored accounts
• When using SQL authentication, use strong passwords
• When using SQL authentication, protect credentials over the network
• When using SQL authentication, protect credentials in configuration files
• Validate untrusted input passed to your data access methods
• When constructing SQL queries, use type safe SQL parameters
• Avoid dynamic queries that accept user input
Exception Management
• Use structured exception handling
• Do not reveal exception details to the client
• Use a global error handler to catch unhandled exceptions
Impersonation/Delegation
• Know your tradeoffs with impersonation
• Avoid Calling LogonUser
• Avoid programmatic impersonation where possible
• If you need to impersonate, consider threading issues
• If you need to impersonate, clean up appropriately
Parameter Manipulation
• Do not make security decisions based on parameters accessible on the client-side
• Validate all input parameters
• Avoid storing sensitive data in ViewState
• Encrypt ViewState if it must contain sensitive data
Sensitive Data
• Avoid plaintext passwords in configuration files
• Use platform features to manage keys where possible
• Do not pass sensitive data from page to page
• Protect sensitive data over the wire
• Do not cache sensitive data
Session Management
• Do not rely on client-side state management options
• Protect your out-of-process state service
• Protect SQL Server session state
Auditing and Logging
• Use health monitoring to log and audit events
• Instrument for user management events
• Instrument for unusual activity
• Instrument for significant business operations
• Consider using an application-specific event source
• Protect audit and log files
Deployment Considerations
• Use a least-privileged account for running ASP.NET applications
• Encrypt configuration sections that store sensitive data
• Consider your key storage location
• Block Protected File Retrieval by Using HttpForbiddenHandler
• Configure the MachineKey to use the same keys on all servers in a Web farm
• Lock configuration settings to enforce policy settings
Communication Security
• Consider SSL vs. IPSec
• Optimize pages that use SSL

No comments: