Authentication

Weak authentication increases the identity spoofing threat. If a user's logon credentials fall into the wrong hands, an attacker can spoof the user's identity and gain access to the application. The attacker shares all of the user's privileges in the application. Credentials must be protected as they are passed over the network and while they are persistent, for example, in the application's user store. The authentication cookie that represents an authenticated identity to the application after the initial logon must also be protected to mitigate the risk of session hijacking and cookie replay attacks.

Forms Authentication

The threat of session hijacking and cookie replay attacks is particularly significant for applications that use Forms authentication. You must take particular care when querying the database using the user-supplied credentials to ensure that you are not vulnerable to SQL injection. Additionally, to prevent identity spoofing, you should make sure that the user store is secure and that strong passwords are enforced.

The following fragment shows a "secure" Forms authentication configuration in Web.config:

 <forms loginUrl="Restricted\login.aspx"  Login page in an SSL protected folder          protection="All"                  Privacy and integrity          requireSSL="true"                 Prevents cookie being sent over http          timeout="10"                      Limited session lifetime          name="AppNameCookie"              Unique per-application name          path="/FormsAuth"                    and path          slidingExpiration="true" >        Sliding session lifetime   </forms> 

The following recommendations help you build a secure Forms authentication solution:

• Partition your Web site .

• Secure restricted pages with SSL .

• Use URL Authorization .

• Secure the authentication cookie .

• Use absolute URLs for navigation .

• Use secure credential management .

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. Figure 10.3 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.

Figure 10.3: Subdirectory for restricted pages that require authenticated access

Note  

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

Secure 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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp .

Use URL Authorization

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

 <system.web>   <!-- The virtual directory root folder contains general pages.        Unauthenticated users can view them and they do not need         to be secured with SSL. -->   <authorization>     <allow users="*" />   </authorization> </system.web> 

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:

 <!-- The restricted folder is for authenticated and SSL access only. --> <location path="Secure" >   <system.web>     <authorization>       <deny users="?" />     </authorization>   </system.web> </location> 

Secure the Authentication Cookie

To prevent session hijacking and cookie replay attacks, secure 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 .

• Encrypt the cookie .

• Limit cookie lifetime .

• Consider using a fixed expiration period .

• Do not persist authentication cookies .

• Keep authentication and personalization cookies separate .

• Use distinct cookie names and paths .

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

Encrypt the cookie contents 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.

Note  

This feature is available with .NET Framework version 1.1.

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 =           HttpUtility.UrlEncode(Request.ServerVariables["SERVER_NAME"]);   string vdirName = Request.ApplicationPath;   Response.Redirect("https://" + serverName + vdirName +                      "/Restricted/Login.aspx"); } 

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.

The following recommendations help you reduce risk:

• Use one-way hashes for passwords .

• Use strong passwords .

• Prevent SQL injection .

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}$"); } 

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."