Security Checklist: ASP.NET 2.0

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

patterns & practices Developer Center

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

Microsoft Corporation

August 2005

Applies To

• ASP.NET version 2.0

Summary

This checklist presents a set of consolidated security guidelines for ASP.NET version 2.0 applications. The answers and recommendations presented in this module are designed to supplement the companion modules and additional guidance. The guidelines are organized by various categories that represent those areas where mistakes are most often made.

Contents

How to Use This Module
Design Considerations
Application Categories Considerations

How to Use This Module

This checklist is a companion to Security Guidelines: ASP.NET 2.0. Use "Security Guidelines: ASP.NET 2.0" to browse the ASP.NET 2.0 guidelines and learn what to do, why, and how. Use this checklist to help you secure your ASP.NET 2.0 application.

Design Considerations

Check	Description
	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.

Application Categories Considerations

Auditing and Logging

Check	Description
	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

Check	Description
	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

Check	Description
	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

Check	Description
	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

Check	Description
	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

Check	Description
	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

Check	Description
	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

Check	Description
	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

Check	Description
	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. If impersonation token is to be passed to newly created threads, the ASPNET.config is configured correctly.
	Impersonation is reverted by using finally blocks.
	Exceptions while impersonating are not allowed to propagate.

Parameter Manipulation

Check	Description
	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

Check	Description
	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

Check	Description
	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

Check	Description
	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

Check	Description
	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.

Feedback

Provide feedback by using either a Wiki or e-mail:

• Wiki. Security Guidance Feedback page: https://channel9.msdn.com/wiki/securityguidancefeedback/
• E-mail. Send e-mail to secguide@microsoft.com.

We are particularly interested in feedback regarding the following:

• Technical issues specific to recommendations
• Usefulness and usability issues

Technical Support

Technical support for the Microsoft products and technologies referenced in this guidance is provided by Microsoft Support Services. For product support information, please visit the Microsoft Product Support Web site at https://support.microsoft.com.

Community and Newsgroups

Community support is provided in the forums and newsgroups:

• MSDN Newsgroups:https://www.microsoft.com/communities/newsgroups/default.mspx
• ASP.NET Forums:http://forums.asp.net

To get the most benefit, find the newsgroup that corresponds to your technology or problem. For example, if you have a problem with ASP.NET security features, you would use the ASP.NET Security forum.

Contributors and Reviewers

• External Contributors and Reviewers: Jason Taylor, Security Innovation; Rudolph Araujo, Foundstone Professional Services
• Microsoft Contributors and Reviewers: Wade Mascia, Tom Christian, Adam Semel, Stefan Schackow
• Test team: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Infosys Technologies Ltd.
• Edit team: Nelly Delgado, Microsoft Corporation; Tina Burden McGrayne, TinaTech Inc.
• Release Management: Sanjeev Garg, Microsoft Corporation

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.