ASP.NET 2.0 Security Inspection Questions - What's New in 2.0

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo


Contents

What's New in 2.0

This section describes the most important changes in ASP.NET 2.0 that you should be aware of when you perform a security code review. The main changes include:

  • Details in configuration files, such as connection strings, can be encrypted by using the Aspnet_regiis tool.
  • There are new membership APIs.
  • There are new role APIs.

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?
  • Does the code ensure that membership providers use strong passwords?
  • Does the code ensure that the roles cookie is encrypted and checked for integrity?
  • Does the code ensure that the roles cookie has a limited life time?
  • Does the code persist role manager cookies?


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>
Personal tools