ASP.NET 2.0 Security Checklists

From Guidance Share

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan

Contents 1 Design Considerations 2 Auditing and Logging 3 Forms Authentication 4 Windows Authentication 5 Authorization 6 Code Access Security 7 Data Access 8 Exception Management 9 Input and Data Validation 10 Impersonation and Delegation 11 Parameter Manipulation 12 Sensitive Data 13 Session Management 14 Deployment Considerations 15 Communication Security

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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