ASP.NET 2.0 Security Checklists
From Guidance Share
- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan
[edit]
Design Considerations
- Security decisions should not rely on client-side validations; they are made on the server side
- The Web site is partitioned into public access areas and restricted areas that require authentication access Navigation between these areas should not flow sensitive credentials information
- The site has granular authorization checks for pages and directories
- Web controls, user controls, and resource access code are all partitioned in their own assemblies for granular security
- Mechanisms have been identified to protect credentials, authentication tickets, and other sensitive information over network and in persistent stores
- Structured exception management is used
- Unrecoverable exceptions don’t leave the system wide open
[edit]
Auditing and Logging
- "Health monitoring is used for logging and auditing events":HealthMonitoringIsUsed
- Logging is throttled so that an attacker can’t overwhelm the logs
- "Sensitive user data is not logged":SensitiveUserDataNotLogged
- "User Management Events are logged":UserManagementEventsLogged
- "Login Activity is Instrumented to Track Suspicious Actions":LoginActivityInstrumented
- Significant Business Operations are Logged
- Audit and Log Files have Restricted Access
- "Application logs to a separate protected server":ApplicationLogsToSeperateServer
- Events are logged with appropriate levels of information to reconstruct system activity
- High volume, per-request events are captured with performance counters
[edit]
Forms Authentication
- Membership providers are used instead of custom authentication
- SSL is used to protect user credentials and authentication cookies
- If using SSL is not possible, the SlidingExpiration attribute is set to false and limited authentication cookie time-outs are used
- User login information is validated using the Regex class and/or your custom validation code
- Hashed password format is specified in provider configuration
- Passwords are not stored directly in the user store; password digests with salt are stored instead
- Strong passwords policies are enforced
- Access to the credential store is limited to application account
- Authentication cookies are not persisted
- Authentication cookie is encrypted and integrity checked
- Authentication cookies are restricted to HTTPS connections only by using the requireSSL attribute
- Absolute URLs are used for navigation where the site is partitioned with secure and non-secure folders
- httpOnlyCookies attribute is set to true on authentication cookie to prevent client side script from accessing the cookie
- Unique cookie names and paths are used
[edit]
Windows Authentication
- Windows authentication is used where possible
- Strong passwords policies are enforced
- Impersonation is used only when original caller's security context is required for downstream tier for auditing or authorization
- Impersonation token is not created by using LogonUser API
- Protocol transition is used when multiple identities need to access downstream resources
[edit]
Authorization
- URL authorization is used for page and directory access control
- File authorization is used with Windows authentication
- Appropriate ACLs are configured on Web site files
- Role manager, instead of custom code, is used for roles authorization
- Role caching is used if role store lookup is too costly
- If role caching is used, authorization cookie is restricted to HTTPS connections by using the requireSSL attribute
- If using SSL is not possible, the cookieSlidingExpiration attribute is set to false and limited authentication cookie time-outs are used
- The authorization cookie is not persisted on user machine by setting the createPersistentCookie attribute to false
- Authorization cookie is protected for tampering and reading information
[edit]
Code Access Security
- Code access security is used when applications need to be isolated from each other
- The chosen trust level does not exceed your application's requirement
- If your application needs additional permissions, a custom trust policy is used
- Applications are isolated using Medium trust in hosted environments
- Attribute allowOverride is set to false in the machine-level Webconfig file to ensure developers cannot change the trust level of their application
[edit]
Data Access
- Connection strings are encrypted in configuration files using the Aspnet_regiis utility and Protected Configuration providers
- Connection string information is encrypted using strong encryption (for example, 3DES)
- Connection to database is used with least-privileged service account
- Windows authentication is used when connecting to SQL Server
- Trusted service accounts are used to connect to SQL Server
- Mirrored local accounts are considered as an alternative if domain accounts cannot be used
- 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
- Credentials in SQL connection strings are protected in configuration files
- RSA Protected Configuration provider is used to protect connection strings in a Web farm environment
- Untrusted input passed to data access methods is validated
- SQL queries use parameterized stored procedures and type-safe SQL parameters
- Dynamic queries that accept user input are used only if stored procedures cannot be used
[edit]
Exception Management
- Structured exception handling is used
- Generic error pages with harmless messages are returned to the client
- Global error handlers are used to catch unhandled exceptions
- Set mode attribute in customErrors to On to prevent displaying detailed error messages to the caller
- Exception details are logged on the server
[edit]
Input and Data Validation
- Application does not rely only on request validation
- All the input is validated for length, range, format, and type Input is checked for known valid and safe data and then for malicious, dangerous data
- Application does not rely on only client-side validation
- Application avoids file name and path input from user where possible
- If input file names are required, they are well formed and are verifiably valid within the application context
- Output that contains untrusted data is encoded with HtmlEncode and UrlEncode
[edit]
Impersonation and Delegation
- Tradeoffs associated with use of impersonation are fully understood
- Use of LogonUser is avoided where possible
- Programmatic impersonation is avoided where possible
- Threading issues have been considered if impersonation is used
- Impersonation is reverted by using finally blocks
- Exceptions while impersonating are not allowed to propagate
[edit]
Parameter Manipulation
- Security decisions are not made based on client parameters
- All the input parameters are validated for type, length, format, and range
- Sensitive data is not stored in view state
- View state is encrypted if it does contain sensitive data
- PageViewStateUserKey is used to counter one-click attacks
- Query strings with server secrets are hashed
[edit]
Sensitive Data
- Plaintext passwords are not used in configuration files (Webconfig and Machineconfig)
- Sensitive data that is stored in config files are encrypted using Protected Configuration providers
- Platform features are used and custom key management is avoided
- Sensitive data is not passed across pages; it is maintained using server-side state management
- Sensitive data passed over wire is secured using SSL or IPSec where appropriate
- Sensitive data is not cached
- Sensitive data is not stored in cookies, hidden form fields, or query strings
- Output caching for pages that contain sensitive data is turned off
- Sensitive data is encrypted in the database
[edit]
Session Management
- Application does not rely on client-side state management options
- Windows authentication is used to connect to Microsoft SQL Server state database
- Session state connection strings are encrypted using protected configuration providers
- Out-of-process state service is protected
- Access to state data is restricted
- SQL Server session state is protected
- The session cookie is protected using SSL on all pages that require authenticated access
- The session state service is disabled if not used
- The session state service (if used) runs using a least-privileged account
- The communication channel to state store is encrypted (IPSec or SSL)
- Session state port is changed from default of 42424
[edit]
Deployment Considerations
- Least-privileged service account is used for running ASPNET applications
- Configuration sections that contain sensitive data are encrypted using protected configuration providers
- Keys are stored in machine-level key store for application on dedicated server or multiple applications that run under the same identity
- Keys are stored in user-level key store for applications running in a shared hosting environment
- Protected file types are blocked using HttpForbiddenHandler
- The same machine keys are used consistently across all servers in a Web farm
- Configuration settings are locked by setting allowOverride to false where appropriate to enforce policy settings
- Set mode attribute in customErrors to On to prevent displaying detailed error messages to the caller
[edit]
Communication Security
- Least-privileged service account is used for running ASPNET applications
- Configuration sections that contain sensitive data are encrypted using protected configuration providers
- Keys are stored in machine-level key store for application on dedicated server or multiple applications that run under the same identity
- Keys are stored in user-level key store for applications running in a shared hosting environment
- Protected file types are blocked using HttpForbiddenHandler
- The same machine keys are used consistently across all servers in a Web farm
- Configuration settings are locked by setting allowOverride to false where appropriate to enforce policy settings
- Set mode attribute in customErrors to On to prevent displaying detailed error messages to the caller