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.

The FormsAuthentication.RedirectFromLoginPage() method issues an authentication ticket, which allows users to remain authenticated for a specified period of time. When the method is invoked with the second argument false, it issues a temporary authentication ticket that remains valid for a period of time configured in web.config. When invoked with the second argument true, the method issues a persistent authentication ticket. On .NET 2.0, the lifetime of the persistent ticket respects the value in web.config, but on .NET 1.1, the persistent authentication ticket has a ridiculously long default lifetime -- fifty years.

Allowing persistent authentication tickets to survive for a long period of time leaves users and the system vulnerable in the following ways:

It expands the period of exposure to session hijacking attacks for users who fail to log out.

It increases the average number of valid session identifiers available for an attacker to guess.

It lengthens the duration of exploit when an attacker succeeds in hijacking a user's session.

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.

Most web applications use a session identifier to uniquely identify users, which is typically stored in a cookie and transmitted transparently between the server and the web browser.


When the value of the attribute is set to either true or UseUri, the application does not use cookies regardless of whether the browser or device supports cookies. When the value of the attribute is set to either AutoDetect or UseDeviceProfile, the cookies are not used depending on the configuration of the requesting browser or device.

Applications that do not store session identifiers in cookies sometimes transmit them as an HTTP request parameter or as part of the URL. Accepting session identifiers specified in URLs makes it easy for attackers to perform Session Fixation attacks.

Placing session identifiers in URLs can also increase the chances of successful Session Hijacking attacks against the application. Session Hijacking occurs when an attacker takes control of a victim's active session or session identifier. It is common practice for web servers, application servers, and web proxies to store requested URLs. If session identifiers are included in URLs, they are also logged. Increasing the number of places session identifiers are viewed and stored increases the chances they will be compromised by an attacker.

ASP.NET applications can be configured to output trace debugging information. Trace output contains details about the request made to the current page, header information, methods, and controls used on the page and the active session state. Attackers may leverage the additional information they gain from trace output to mount attacks targeted on the framework, database, or other resources used by the application.

Trace information is enabled at the page level by setting the Trace attribute of the <page> directive to true or on the application level by adding a trace element in the web.config file and setting its enabled attribute to true.

Insecure HTTP header processing exists by setting the useUnsafeHeaderParsing property to true. This setting enables attacks against vulnerable applications because of insufficient validation rules on HTTP headers.




The following validation is NOT performed when this attribute is set to true:

- Use CRLF for end-of-line code. A separate CR or LF is not permitted.
- No spaces in header names.
- All but the first status line is interpreted as a faulty header name/value pair.
- The status line must include a code and a description.

This setting additionally means that certain exceptions concerning prohibited characters will no longer be thrown.

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

...
<configuration>
   <system.net>
   <settings>
      <httpWebRequest useUnsafeHeaderParsing="true" />
   </settings>
   </system.net>
</configuration>
...