Return to HomePage

---

Note: This document is now live on MSDN! _See _Security Checklist: ASP.NET 2.0'' at http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGCK0001.asp

Security Checklist: ASP.NET 2.0

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

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 identities used to access remote resources from ASP.NET Web applications are clearly identified.
* Mechanisms have been identified to secure credentials, authentication tickets, and other sensitive information over network and in persistent stores.
* A secure approach to exception management is identified. The application fails securely in the event of exceptions.
* 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.

Auditing and Logging

* Health monitoring is used for logging and auditing events.
* Application is instrumented for user management events such as authentication success and failures, password resets, password changes, and account lockout.
* Application is instrumented for unusual activity such as multiple login attempts and replayed authentication tickets.
* Access to significant business logic is instrumented.
* Access to audit and log files are restricted, with application accounts having write access, administrative accounts having full access, and operators have read access.
* Application and audit events are logged on separate protected server.
* Events are logged with appropriate levels of information to reconstruct system activity.
* High volume, per-request events are captured with performance counters.

Authentication–Forms

* 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.
* Site is partitioned to restricted areas and public areas.
* 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.

Authentication–Windows

* 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 Web.config 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/Data Validation

* Free form input is sanitized to clean malicious data.
* 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.
* Input from all the sources including query strings, cookies, and HTML controls is validated using the Regex class and/or your custom validation code.
* 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.
* Untrusted output is not directly echoed back to the user.
* Output that contains untrusted data is encoded with HtmlEncode and UrlEncode.

Impersonation/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.
* Page.ViewStateUserKey is used to counter one-click attacks.
* Query strings with server secrets are hashed.

Sensitive Data

* Plaintext passwords are not used in configuration files (Web.config and Machine.config).
* 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 ASP.NET 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

* Appropriate mechanism of secure communication (IPSec or SSL) is used, depending on application requirement.
* For communication between Web browser and Web server, SSL is used when pages need to be encrypted and you need to guarantee that the server to which you send the data is the server that you expect.
* For communication between servers, IPSec is used when secure server-to-server communication is required.
* For communication between servers, SSL is used when an application does not trust other applications on a server.
* Pages that use SSL are optimized.

---

Return to HomePage