Security Auditing and Vulnerability Scan Services

• Security decisions should not rely upon client-side validations; they are made on the server side.
• The website is partitioned into public access areas and restricted areas that require authentication access.
• Navigation between public and restricted areas should not flow sensitive credentials information.
• The identities used to access remote resources from ASP.NET web applications are clearly identified.
• Mechanisms are in place to secure credentials, authentication tickets, and other sensitive data.
• A secure approach to exception management has been identified.
• The site has granular authorization checks for pages and directories.
• Web controls, user controls, and resource access code are each partitioned in their own assemblies.

• Do not rely upon ASP.NET request validation.
• Validate input data 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.

• 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.

• Choose Windows authentication when you can.
• Enforce strong password policies.

• Use URL authorization for page and directory access control.
• Configure ACLs on your website files.
• Use ASP.NET role manager for roles authorization.
• If your role lookup is expensive, consider role caching.
• Protect your authorization cookie.

• 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.

• 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 and 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.

• Use structured exception handling.
• Do not reveal exception details to the client.
• Use a global error handler to catch unhandled exceptions.

• Know your tradeoffs with impersonation.
• Avoid calling LogonUser.
• Avoid programmatic impersonation where possible.
• If you need to impersonate, consider threading issues and clean up appropriately.
• Avoid losing impersonation tokens.

• Do not make security decisions based upon parameters accessible on the client side.
• Validate all input parameters.
• Avoid storing sensitive data in ViewState.
• Encrypt ViewState if it must contain 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.

• Do not rely upon client-side state management options.
• Protect your out-of-process state service.
• Protect SQL Server session state.

• Use health monitoring to log and audit events.
• Instrument for user management events and unusual activity.
• Instrument for significant business operations.
• Consider using an application-specific event source.
• Protect audit and log files.

• 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.

• Consider SSLv3 or TLS vs. earlier SSL versions or IPSec.
• Optimize pages that use SSL.