If the cacheRolesInCookie attribute of the configuration/system.web/authentication/forms element in web.config is set to true, then the roles for each user are cached in a cookie. If this information is stored in plain text, anyone with access to machines used to interact with the application will have access to the information stored in the cookie. Worse yet, if attackers are allowed to arbitrarily modify the data stored in cookies, they can falsify information provided to the application and potentially alter its behavior to their advantage.

In many cases, an application can validate input from cookies programmatically according to the context in which it is used, but the ASP.NET validation framework provides an excellent way to verify that the cookie has not been modified unexpectedly. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.

ASP.NET Web services facilitate the development of Web services clients by automatically generating documentation that describes how to communicate with the Web service.

Web services that have the documentation protocol enabled generate an HTML-formatted page when a browser request is received.

This HTML-formatted page describes the following information:
1. The operations that are supported
2. The parameters that each operation accepts
3. The type of data that should be passed in those parameters

The documentation protocol also generates an XML-formatted Web Services Description Language (WSDL) file. This file is designed to allow applications to understand how to structure requests to the Web service. This information can be very useful to developers, especially developers who create clients for public Web services. However, revealing detailed information about the functionality of private Web services increases the risk that the Web service will be misused by a malicious attacker. The Documentation protocol always describes all functions and parameters of a Web service -- even if only a subset of those functions are intended to be publicly accessible.

ASP .NET applications should be configured to use custom error pages instead of the framework default page. The default error page gives detailed information about the error that occurred, and should not be used in production environments. The mode attribute of the <customErrors> tag defines whether custom or default error pages are used.

Attackers may leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.

By default, ASP.NET internally validates the cryptographic signatures before decrypting payloads such as ViewState, FormsAuth cookies, and ScriptResource.axd URLs and passes those values to the application for further processing. However, this functionality can be modified using the aspnet:UseLegacyEncryption setting to disable the cryptographic signature verification before decrypting payloads. This may allow a malicious client to decrypt, forge, or otherwise tamper with encrypted data.

Example 1: In the following example, aspnet:UseLegacyEncryption is set to true.

...
  <appSettings>
    <add key="aspnet:UseLegacyEncryption" value="true" />
  </appSettings>
...

ASP.NET applications can store user name and password pairs in <credentials> elements in the web.config file for an ASP.NET application, which supports plain text, MD5 and SHA1 password formats.

Passwords stored in plain text or using a weak encryption algorithm are accessible to anyone with the access to the application's configuration files. This may include the machine where the application is hosted or the source code repository where the application lives.

Example 1: The following web.config entry incorrectly stores its passwords in plain text.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET supports credential passwords stored in three formats, specified by the passwordFormat attribute of the configuration/system.web/authentication/forms/credentials element. The possible values for this attribute are:

Clear - indicates that the password is stored in plain text (least secure)
MD5 - indicates that the password's MD5 hash is stored
SHA1 - indicates that the password's SHA1 hash is stored (most secure)

While an MD5 hash is more secure than plain text, researchers have found brute-force attacks against the MD5 hashing algorithm. At this time, a SHA1 hash still provides reasonable protection against such attacks.

Unchecked input is the leading cause of vulnerabilities in ASP.NET applications. Unchecked input can lead to numerous vulnerabilities, including cross-site scripting, process control, and SQL injection.

To prevent such attacks, use the ASP.NET validation framework to check all program input before it is processed by the application.

Example uses of the validation framework include checking to ensure that:

- Phone number fields contain only valid characters in phone numbers

- Boolean values are only "T" or "F"

- Free-form strings are of a reasonable length and composition

If the cacheRolesInCookie attribute of the configuration/system.web/authentication/forms element in web.config is set to true, then the roles for each user are cached in a cookie. If this information is stored in plain text, anyone with access to machines used to interact with the application will have access to the information stored in the cookie. Worse yet, if attackers are allowed to arbitrarily modify the data stored in cookies, they can falsify information provided to the application and potentially alter its behavior to their advantage.

In many cases, an application can validate input from cookies programmatically according to the context in which it is used, but the ASP.NET validation framework provides an excellent way to verify that the cookie has not been modified unexpectedly. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.