ASP.NET 1.1 Security Guidelines - Authentication

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Partition your Web site

In your site design, make sure that secure pages that require authenticated access are placed in a subdirectory that is separate from the anonymously accessible pages. Following figure shows a typical arrangement in the Visual Studio .NET Solution Explorer window. Notice how the Forms login page is placed along with other restricted pages in a separate subdirectory.

Note If you are using Server.Transfer in your application to transfer from an anonymous page to a secure page, the .NET Framework bypasses authentication checks, so code that uses Server.Transfer should be verified to ensure that it does not transfer to a secure directory.


Protect restricted pages with SSL

To ensure that SSL is used to protect the logon credentials that are posted from the login form, and that the authentication cookie passed on subsequent requests to restricted pages, configure the secure folders in IIS to require SSL. This sets the AccessSSL=true attribute for the folder in the IIS metabase. Requests for pages in the secured folders will only be successful if https is used on the request URL.

For SSL, you must have a server certificate installed on the Web server. For more information, see "How To: Setup SSL on a Web Server" in the "How To" section of "Microsoft patterns & practices Volume I, Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication" at


Use URL Authorization

To allow anonymous access to public pages, use the following <authorization> element.

   <allow users="*" />

Use the following <authorization> element inside a <location> element in Web.config to deny access to unauthenticated users and force a redirect to the login page that is specified on the <forms> element:

<location path="Secure" >
     <deny users="?" />


Protect the authentication cookie

To prevent session hijacking and cookie replay attacks, protect the cookie by making sure that it is only passed over SSL connections using the HTTPS protocol. For additional risk mitigation, encrypt the cookie before sending it to the client and limit the period for which the cookie is valid. To secure the authentication cookie:

Restrict the Authentication Cookie-to-HTTPS Connections

Cookies support a "secure" property that determines whether or not browsers should send the cookie back to the server. With the secure property set, the cookie is sent by the browser only to a secure page that is requested using an HTTPS URL.

If you are using .NET Framework version 1.1, set the secure property by using requireSSL="true" on the <forms> element as follows:

<forms loginUrl="Secure\Login.aspx"
      requireSSL="true" . . . />

If you are using .NET Framework version 1.0, set the secure property manually in the Application_EndRequest event handler in Global.asax using the following code:

protected void Application_EndRequest(Object sender, EventArgs e) 
 string authCookie = FormsAuthentication.FormsCookieName;
 foreach (string sCookie in Response.Cookies) 
   if (sCookie.Equals(authCookie))
     // Set the cookie to be secure. Browsers will send the cookie
     // only to pages requested with https
     Response.Cookies[sCookie].Secure = true;

Encrypt the Cookie and Check Its Integrity

Encrypt the cookie and check its integrity, even if you are using SSL. This prevents an attacker from viewing or modifying the cookie if he or she manages to steal it through a XSS exploit. In this event, the attacker can still use the cookie to gain access to your application. The best way to mitigate this risk is to implement the appropriate countermeasures to prevent XSS attacks (described under "Cross-Site Scripting" earlier in this chapter), and limit the cookie lifetime as described in the next recommendation.

To provide privacy and integrity for the cookie, set the protection attribute on the <forms> element as follows:

<forms protection="All"    Privacy and integrity

Limit Cookie Lifetime

Limit the cookie lifetime to reduce the time window in which an attacker can use a captured cookie to gain spoofed access to your application.

<forms timeout="10"                Reduced cookie lifetime (10 minutes)

Consider Using a Fixed Expiration Period

Consider setting slidingExpiration="false" on the <forms> element to fix the cookie expiration, rather than resetting the expiration period after each Web request. This is particularly important if you are not using SSL to protect the cookie.

Do not Persist Authentication Cookies

Do not persist authentication cookies because they are stored in the user's profile and can be stolen if an attacker gets physical access to the user's computer. You can specify a non-persistent cookie when you create the FormsAuthenticationTicket as follows:

FormsAuthenticationTicket ticket = 
              new FormsAuthenticationTicket(
                       1,                           // version
                       Context.User.Identity.Name,  // user name
                       DateTime.Now,                // issue time
                       DateTime.Now.AddMinutes(15), // expires every 15 mins
                       false,                       // do not persist the cookie
                       roleStr );                   // user roles

Keep Authentication and Personalization Cookies Separate

Keep personalization cookies that contain user-specific preferences and non-sensitive data separate from authentication cookies. A stolen personalization cookie might not represent a security threat, whereas an attacker can use a stolen authentication cookie to gain access to your application.

Use Distinct Cookie Names and Paths

Use unique name and path attribute values on the <forms> element. By ensuring unique names, you prevent possible problems that can occur when hosting multiple applications on the same server. For example, if you don't use distinct names, it is possible for a user who is authenticated in one application to make a request to another application without being redirected to that application's logon page.

For more information, see Microsoft Knowledge Base articles 313116, "PRB: Forms Authentication Requests Are Not Directed to loginUrl Page," and 310415, "PRB: Mobile Forms Authentication and Different Web Applications."


Use absolute URLs for navigation

Navigating between the public and restricted areas of your site (that is, between HTTP and HTTPS pages) is an issue because a redirect always uses the protocol (HTTPS or HTTP) of the current page, not the target page.

Once a user logs on and browses pages in a directory that is secured with SSL, relative links such as "..\publicpage.aspx" or redirects to HTTP pages result in the pages being served using the https protocol, which incurs an unnecessary performance overhead. To avoid this, use absolute links such as "http://servername/appname/publicpage.aspx" when redirecting from an HTTPS page to an HTTP page.

Similarly, when you redirect to a secure page (for example, the login page) from a public area of your site, you must use an absolute HTTPS path, such as "https://servername/appname/secure/login.aspx", rather than a relative path, such as restricted/login.aspx. For example, if your Web page provides a logon button, use the following code to redirect to the secure login page.

private void btnLogon_Click( object sender, System.EventArgs e )
 // Form an absolute path using the server name and v-dir name
 string serverName = 
 string vdirName = Request.ApplicationPath;
 Response.Redirect("https://" + serverName + vdirName + 


Use secure credential management

Identity spoofing is one of the most common authentication-related threats to your application. Identity spoofing occurs when an attacker gains access to the application under the guise of another user. One way to do this is to hijack the session cookie, but if you have secured the authentication cookie as described earlier, the risk is significantly reduced. In addition, you must build secure credential management and a secure user store to mitigate the risk posed by brute force password attacks, dictionary attacks, and SQL injection attacks.

Use One-Way Hashes for Passwords

If your user store is SQL Server, store one-way password digests (hash values) with an added random salt value. The added salt value mitigates the risk of brute force password cracking attempts, for example, dictionary attacks. The digest approach means you never actually store passwords. Instead, you retrieve the password from the user and validate it by recalculating the digest and comparing it with the stored value.

Use Strong Passwords

Use regular expressions to ensure that user passwords conform to strong password guidelines. The following regular expression can be used to ensure that passwords are between 8 and 10 characters in length and contain a mixture of uppercase, lowercase, numeric, and special characters. This further mitigates the dictionary attack risk.

private bool IsStrongPassword( string password )
   return Regex.IsMatch(password, @"^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$");

Note When using the Membership feature in ASP.NET 2.0 for Forms authentication, you can configure the membership providers for password strengths. For more information on using the Membership feature in ASP.NET 2.0, see "How To: Use Membership in ASP.NET 2.0." at

Prevent SQL Injection

Forms authentication is especially prone to vulnerabilities that lead to SQL injection attacks because of the way that the user-supplied logon credentials are used to query the database. To mitigate the risk:

  • Thoroughly validate the supplied credentials. Use regular expressions to make sure they do not include SQL characters.
  • Use parameterized stored procedures to access the user store database.
  • Use a login to the database that is restricted and least privileged.

For more information about preventing SQL injection, see Chapter 14, "Building Secure Data Access." at


Personal tools