ASP.NET 2.0 Security Checklists

From Guidance Share

Jump to: navigation, search

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


Contents

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
Personal tools