Security in ASP.NET Web application

Post date: Mar 18, 2011 11:45:13 AM

Use the following questions to make sure that the code uses the new ASP.NET 2.0 features properly:

Does the code ensure that the connection strings configuration section is encrypted?

When the code specifies the connection string in the connectionStrings configuration section, make sure that the connection strings configuration section is encrypted with the Aspnet_regiis.exe utility.

Because the connection string contains sensitive data, leaving it in plain-text format in configuration files makes your application vulnerable. For more information on encrypting the configuration section, see "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI" at http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000005.asp and "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA" at http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000006.asp.

Does the code ensure that membership providers use strong passwords?

The code should ensure that the membership provider uses a strong password policy by setting minRequiredPasswordLength, minRequiredNonAlphaNumericCharacters, and  passwordStrengthRegularExpression attributes.

Because using weak passwords makes your application vulnerable to brute force and dictionary attacks, it is important to ensure that your Membership feature uses strong passwords.

The application should not contain code similar to the following example.

<membership>

  <providers>

    <add minRequiredPasswordLength="1" .../>

  </providers>

</membership>

  

Instead, the application should contain code similar to the following.

<membership>

  <providers>

    <add minRequiredPasswordLength="7", 

         minRequiredNonAlphanumericCharacters="1", 

         passwordStrengthRegularExpression ="" ... />

  </providers>

</membership>

  

Note   By default, the password strength policy for SqlMembershipProvider and ActiveDirectoryMembershipProvider has a minimum length of 7 characters and 1 non-alphanumeric character.

Does the code ensure that the roles cookie is encrypted and checked for integrity?

Make sure that the roles cookie is encrypted and checked for integrity. The cookieProtection attribute should be set to "All", which is the default case.

Cookies that are not encrypted and tamperproof make your application vulnerable to privilege escalation attacks through unauthorized modification of the role data.

The application should not contain code similar to the following example.

<system.web>

  <roleManager cookieProtection="None" ... />

</system.web>

  

Instead, the application should contain code similar to the following.

<system.web>

  <roleManager cookieProtection="All" ... />

</system.web>  

Does the code ensure that the roles cookie has a limited life time?

A shorter life time limits the time when an attacker can use a stolen cookie to access the application.

The application should not contain code similar to the following example.

<system.web>

  <roleManager cookieTimeout="100" ... />

</system.web>  

Instead, the application should contain code similar to the following.

<system.web>

  <roleManager cookieTimeout="10" ... />

</system.web>

  

Does the code persist role manager cookies?

Make sure that the roles cookie is not stored on the client by setting the createPersistentCookie attribute to false.

The code should not persist role manager cookies because they are stored in the user's profile and can be stolen if an attacker gains physical access to the user's computer. Role manager cookies can reveal sensitive information about your application's role structure that an attacker can exploit.

The application should not contain code similar to the following example.

<system.web>

  <roleManager createPersistentCookie="true" ... />

</system.web>

  

Instead, the application should contain code similar to the following.

<system.web>

  <roleManager createPersistentCookie="false" ... />

</system.web>