Summary
This module presents a set of consolidated ASP.NET version 2.0 security guidelines. You can use these guidelines to learn security best practices for design, implementation, and deployment. The guidelines can also be used to check an existing application during security review. Each guideline organizes key information and explains what to do, why you should do it, and how you can implement it. Detailed step-by-step instructions for more complex procedures required to implement a guideline are provided by companion How To modules to which the guidelines refer. This guideline module has a corresponding checklist that summarizes the security guidelines. For the checklist, see "Security Checklist: ASP.NET 2.0." This module also includes an index of guidelines for ASP.NET version 2.0 applications.
How to Use This Module
To get the most from this module:
- Use the index to browse the guidelines. Use the index to scan across the guidelines and to quickly jump to a specific guideline.
- Learn the guidelines. Browse the guidelines to learn security best practices for design, implementation, and deployment. Each guideline explains what to do, why, and how.
- Use the companion How To modules. Refer to the associated How To modules for more detailed step-by-step implementation details. They describe how to implement the more complex solution elements required to apply a guideline.
- Use the companion checklist. Use the associated checklist as a quick reference job aid to help you learn and implement the guidelines.
What's New in 2.0
The .NET Framework version 2.0 and ASP.NET version 2.0 introduce many new security features. The most notable enhancements for ASP.NET Web applications are:
- Forms authentication and membership. You can now use forms authentication with the new membership feature and membership API. The membership feature supports a provider model, with the SqlMembershipProvider for SQL Server databases and ActiveDirectoryMembershipProvider for Microsoft Active Directory® and Active Directory Application Mode (ADAM) stores provided as built-in providers. You can also create custom providers for your custom user stores. You no longer have to create your own custom databases and write your own custom authentication code.
- Role manager. The new role management feature provides protected role storage and an API for managing and checking role membership. The role manager supports a provider model. The supplied providers are:
- The SqlRoleProvider for SQL Server role stores.
- The WindowsTokenRoleProvider used with Windows authentication, which uses Windows groups as roles.
- The AuthorizationStoreRoleProvider, which uses Windows Server 2003 Authorization Manager for managing roles in Active Directory or ADAM.
- DPAPI managed wrapper. The .NET Framework version 2.0 provides a set of managed classes to access the Win32 Data Protection API (DPAPI). Code requires the DataProtectionPermission to be able to use DPAPI.
- Configuration file changes. Machine-wide configuration settings for all Web applications on a server are now maintained in a machine-level Web.config file instead of Machine.config. The machine-level Web.config file is located in the \Windows\Microsoft.NET\Framework\{version}\CONFIG directory.
- Configuration file encryption. ASP.NET version 2.0 introduces a Protected Configuration feature to enable you to encrypt sections of your Machine.config and Web.config files by using either DPAPI or RSA encryption. This is particularly useful for encrypting connection strings and account credentials.
- Health monitoring. ASP.NET version 2.0 introduces a health monitoring system. It supports many standard events that you can use to monitor the health of your application. Examples of security related events that are automatically generated include logon failures and successes when using the ASP.NET membership system, attempts to tamper with or reuse forms authentication tickets, and infrastructure events such as disk access failures. You can also create custom events to instrument your application for other security and non-security related notable events.
- Code access security. The SQL Server managed data provider no longer demands Full trust. This means that Medium trust Web applications can now access SQL Server databases by using this provider. Also, in version 2.0, SmtpPermission is available at Full, High, and Medium trust levels. This allows partial trust Web applications to send e-mail.
- MachineKey enhancements. The <machineKey> now supports a decryption attribute that specifies the symmetric encryption algorithm used to encrypt and decrypt forms authentication tickets. ASP.NET version 2.0 provides support for AES symmetric encryption, which is used by default, in addition to DES and 3DES.
- Impersonation token can be retained in new thread. In .NET Framework 2.0, by default the impersonation token still does not flow across threads, but for ASP.NET 2.0 applications you can configure ASP.NET to flow the impersonation token to newly created threads.
Input/Data Validation
If you make unfounded assumptions about the type, length, format, or range of input, your application is unlikely to be robust. Input validation can become a security issue if an attacker discovers that you have made unfounded assumptions. The attacker can then supply carefully crafted input that compromises your application. The misplaced trust of user input is one of the most common and serious vulnerabilities in Web applications.
To help avoid input data validation vulnerabilities:
- Do not rely on ASP.NET request validation.
- Validate input for length, range, format, and type.
- Validate input from all sources like QueryString, cookies, and HTML controls.
- Do not rely on client-side validation.
- Avoid user-supplied file name and path input.
- Do not echo untrusted input.
- If you need to write out untrusted data, encode the output.
Do Not Rely on ASP.NET Request Validation
The ASP.NET request validation feature performs basic input validation. Do not rely on it. Use it as an extra precautionary measure in addition to your own input validation. Only you can define what represents good input for your application.
Request validation is enabled by default. You can see this by examining the validateRequest attribute, which is set to true on the <pages> element in the Machine.config.comments file. Ensure that it is enabled for all pages except those that need to accept a range of HTML elements. If you need to disable it for a page, set the ValidateRequest attribute to false by using the @ Page directive.
Validate Input for Length, Range, Format, and Type
Do not trust input. An attacker passing malicious input can attempt SQL injection, cross-site scripting, and other injection attacks that aim to exploit your application's vulnerabilities. Check for known good data and constrain input by validating it for type, length, format, and range. For Web form applications that obtain input through server controls, use the ASP.NET validator controls, such as the RegularExpressionValidator, RangeValidator, and CustomValidator, to validate and constrain input. Check all numeric fields for type and range. If you are not using server controls, you can use regular expressions and the Regex class, and you can validate numeric ranges by converting the input value to an integer or double and then performing a range check.
Validate Input from All Sources Like QueryString, Cookies, and HTML Controls
Most Web applications accept input from various sources, including HTML controls, server controls, query strings, and cookies. Validate input from all of these sources to help prevent injection attacks. Use regular expressions to help validate input. The following example shows how to use the Regex class.
using System.Text.RegularExpressions ;
// Instance method:
Regex reg = new Regex(@"^[a-zA-Z'.\s]{1,40}$");
Response.Write(reg.IsMatch(Request.QueryString["Name"]));
// Static method:
if (!Regex.IsMatch(Request.QueryString["Name"],@"^[a-zA-Z'.\s]{1,40}$"))
{
// Name does not match expression
}
If you cannot cache your regular expression for frequent use, you should use the static IsMatch method where possible for performance reasons, to avoid unnecessary object creation.
Do Not Rely on Client-Side Validation
Do not rely on client-side validation because it can be easily bypassed. For example, a malicious user could disable your client-side script routines by disabling JavaScript. Use client-side validation in addition to server-side validation to reduce round trips to the server and to improve the user experience.
Avoid User-Supplied File Name and Path Input
Where possible, avoid writing code that accepts user-supplied file or path input. Failure to do this can result in attackers coercing your application into accessing arbitrary files and resources. If your application must accept input file names, file paths, or URL paths, you need to validate that the path is in the correct format and that it points to a valid location within the context of your application.
File Names
Ensure that file paths only refer to files within your application's virtual directory hierarchy if that is appropriate. When checking file names, obtain the full name of the file by using the System.IO.Path.GetFullPath method.
File Paths
If you use MapPath to map a supplied virtual path to a physical path on the server, use the overloaded Request.MapPath method that accepts a bool parameter so that you can prevent cross-application mapping. The following code example shows this technique.
try
{
string mappedPath = Request.MapPath( inputPath.Text,
Request.ApplicationPath, false);
}
catch (HttpException)
{
// Cross-application mapping attempted
}
The final false parameter prevents cross-application mapping. This means that a user cannot successfully supply a path that contains ".." to traverse outside of your application's virtual directory hierarchy. Any attempt to do this results in an exception of type HttpException.
Do Not Echo Untrusted Input
Do not echo input back to the user without first validating and/or encoding the data. Echoing input directly back to the user makes your application susceptible to malicious input attacks, such as cross-site scripting.
If You Need to Write Out Untrusted Data, Encode the Output
If you write output that includes user input or data from a shared database or a local file that you do not trust, encode it. Echoing input directly back to the user makes your application vulnerable to cross-site scripting attacks. Encoding the data ensures that it is treated as literal text and not as script. You can use the HttpUtility.HtmlEncode method. Similarly, if you write URLs that might contain unsafe characters because they have been constructed from input data or data from a shared database, use HttpUtilty.UrlEncode to make them safe.
Note Make sure that you encode data at the last possible opportunity before the data is returned to the client.
Additional Resources
For additional resources on input validation, see the following How Tos:
Authentication
Where possible, you should use Windows authentication because this enables you to use an existing identity store such as your corporate Active Directory, it enables you to enforce strong password policies, you do not need to build custom identity store management tools and passwords are not transmitted over the network.
ASP.NET creates an Identity object that implements the System.Security.Principal.IIdentity interface to represent the authenticated user. Regardless of authentication method, you access the authenticated user through HttpContext.Current.User.
If your application is configured for Windows authentication, Internet Information Services (IIS) authenticates the user and the user's Windows token is passed to ASP.NET. ASP.NET constructs a System.Security.Principal.WindowsIdentity object, which contains the user's token, places this inside a System.Security.Principal.WindowsPrincipal object, and then attaches this to the current Web request.
When your application is configured for a non-Windows authentication mechanism such as forms authentication, the Windows token passed by IIS to ASP.NET is a token for the anonymous Internet user account IUSR_MACHINENAME. With forms authentication, ASP.NET constructs a System.Web.Security.FormsIdentity object and places it inside a System.Security.Principal.GenericPrincipal object before attaching it to the current Web request.
This section provides guidance on forms authentication and Windows authentication:
- Forms authentication
- Windows authentication
Forms Authentication
To protect forms authentication, you need to protect user-supplied credentials, the credential store and the authentication ticket. To do this, use the following guidelines:
- Use membership providers instead of custom authentication.
- Use SSL to protect credentials and authentication cookies.
- If you cannot use SSL, consider reducing session lifetime.
- Validate user login information.
- Do not store passwords directly in the user store.
- Enforce strong passwords.
- Protect access to your credential store.
- Do not persist authentication cookies.
- Restrict authentication tickets to HTTPS connections.
- Consider partitioning your site to restricted areas and public areas.
- Use unique cookie names and paths.
Use Membership Providers Instead of Custom Authentication
In ASP.NET version 1.1, you had to implement custom logic for validating user credentials, performing user management, and managing the authentication ticket. In version 2.0, you can use the built-in membership feature. The membership feature helps protect credentials, can enforce strong passwords, and provides consistent APIs for user validation and secure user management. The membership feature also automatically creates the authentication ticket for you.
The membership feature has built-in providers for user stores including SQL Server, Active Directory, and Active Directory Application Mode (ADAM). If you want to use an existing user store, such as a non-Active Directory LDAP directory, or a user store on another platform, create a custom membership provider inheriting from the MembershipProvider abstract base class. By doing this, your application can still benefit from using the standard membership features and API and login controls.
For more information, see How To: Use Membership in ASP.NET 2.0.
Use SSL to Protect Credentials and Authentication Cookies
Use Secure Sockets Layer (SSL) to protect the authentication credentials and authentication cookies passed between browser and server. By using SSL, you prevent an attacker monitoring the network connection to obtain authentication credentials and capturing the authentication cookie to gain spoofed access to your application.
If You Cannot Use SSL, Consider Reducing Session Lifetime
If you cannot use SSL, limit the cookie lifetime to reduce the time window in which an attacker can use a captured cookie to gain access to your application with a spoofed identity. The default timeout for an authentication cookie is 30 minutes. Consider reducing this to 10 minutes as shown here.
timeout="00:10:00"
slidingExpiration="true"... />
The slidingExpiration="true" setting ensures that the expiration period is reset after each Web request. With the preceding configuration, this means that the cookie only times out after a 10 minute period of inactivity.
If you are in a scenario where you are concerned about cookie hijacking, consider reducing the timeout and setting slidingExpiration="false". If sliding expiration is turned off, the authentication cookie expires after the timeout period whether or not the user is active. After the timeout period, the user must re-authenticate.
Validate User Login Information
Validate user login information including user names and passwords for type, length, format, and range. Use regular expressions to constrain the input at the server. If you are not using the SqlMembershipProvider and need to develop your own queries to access your user store database, do not use login details to dynamically construct SQL statements because this makes your code susceptible to SQL injection. Instead, validate the input and then use parameterized stored procedures.
Also encode login details before echoing them back to the user's browser to prevent possible script injection. For example, use HtmlEncode as shown here.
Response.Write(HttpUtility.HtmlEncode("Welcome " + Request.Form["username"]));
Do Not Store Passwords Directly in the User Store
Do not store user passwords either in plaintext or encrypted format. Instead, store password hashes with salt. By storing your password with hashes and salt, you help prevent an attacker that gains access to your user store from obtaining the user passwords. If you use encryption, you have the added problem of securing the encryption key. Use one of the membership providers to help protect credentials in storage and where possible, specify a hashed password format on your provider configuration.
If you must implement your own user stores, store one-way password hashes with salt. Generate the hash from a combination of the password and a random salt value. Use an algorithm such as SHA256. If your credential store is compromised, the salt value helps to slow an attacker who is attempting to perform a dictionary attack. This gives you additional time to detect and react to the compromise.
Enforce Strong Passwords
Ensure that your passwords are complex enough to prevent users guessing other users' passwords and to prevent successful dictionary attacks against your user credential store.
By default, the ASP.NET membership providers enforce strong passwords. For example, the SqlMembershipProvider and the ActiveDirectoryMembership providers ensure that passwords are at least seven characters in length with at least one non-alphanumeric character. Ensure that your membership provider configuration enforces passwords of at least this strength. To configure the precise password complexity rules enforced by your provider, you can set the following additional attributes:
- passwordStrengthRegularExpression. The default is "".
- minRequiredPasswordLength. The default is 7.
- minRequiredNonalphanumericCharacters. The default is 1.
Note The default values shown here apply to the SqlMembershipProvider and the ActiveDirectoryMembershipProvider. The ActiveDirectoryMembershipProvider also verifies passwords against the default domain password policy.
Protect Access to Your Credential Store
Ensure only those accounts that require access are granted access to your credential store. This helps to protect the credential store by limiting access to it. For example, consider limiting access to only your application's account. Ensure that the connection string used to identify your credential store is encrypted.
Also consider storing your credential database on a physically separate server from your Web server. This makes it harder for an attacker to compromise your credential store even if he or she manages to take control of your Web server.
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. To ensure a non-persistent cookie, set the DisplayRememberMe property of the Login control to false. If you are not using the login controls, you can specify a non-persistent cookie when you call either the RedirectFromLoginPage or SetAuthCookie methods of the FormsAuthentication class having validated the user's credentials, as shown here.
public void Login_Click(object sender, EventArgs e)
{
// Is the user valid?
if (Membership.ValidateUser(userName.Text, password.Text))
{
// Parameter two set to false indicates non-persistent cookie
FormsAuthentication.RedirectFromLoginPage(username.Text, false);
}
else
{
Status.Text = "Invalid credentials. Please try again.";
}
}
Restrict Authentication Tickets to HTTPS Connections
Set the secure property of the authentication cookie to ensure that browsers only send authentication cookies over HTTPS connections. By using SSL, you prevent an attacker from capturing the authentication cookie to gain spoofed access to your application.
Set the secure property by using requireSSL="true" on the <forms> element as shown here.
Consider Partitioning Your Site to Restricted Areas and Public Areas
To avoid the performance overhead of using SSL across your entire site, consider using a separate folder to help protect pages that require authenticated access. Configure that folder in IIS to require SSL access. Those pages that support anonymous access can safely be accessed over HTTP connections.
Use Unique 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 do not 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.
Additional Considerations
In addition to the preceding guidelines, consider the following.
- Set httpOnly on the authentication cookie. Set the httpOnlyCookies attribute on the authentication cookie. Internet Explorer 6 Service Pack 1 supports this attribute, which prevents client-side script from accessing the cookie from the document.cookie property. The System.Net.Cookie class in .NET Framework version 2.0 supports an HttpOnly property. The HttpOnly property is always set to true by forms authentication.
Additional Resources
For additional resources on forms authentication, see the following How Tos:
Windows Authentication
If you use Windows authentication, consider the following guidelines:
- Choose Windows authentication when you can.
- Enforce strong password policies.
Choose Windows Authentication When You Can
When possible, use Windows authentication to authenticate your users. By using Windows authentication with Active Directory, you benefit from a unified identity store, centralized account administration, enforceable account and password policies, and strong authentication that avoids sending passwords over the network.
Enforce Strong Password Policies
To help ensure that users cannot guess one another's passwords and to help prevent successful dictionary attacks in the event your password store is compromised, enforce strong passwords through Active Directory policy. To enforce a strong password policy:
- Set password length and complexity. Strong passwords are eight or more characters and must include both alphabetical and numeric characters. The default enforced by the ActiveDirectoryMembershipProvider is seven characters with at least one non-alphanumeric character. If you use this provider, the provider settings are checked first, followed by the Active Directory settings. Users must supply passwords that conform to the stronger of the two.
- Set password expiration. Passwords that expire regularly reduce the likelihood that an old password can be used for unauthorized access. Frequency of expiration is usually guided by a company's security policy. You should define this in Active Directory.
For more information on forms authentication, see How To: Use Windows Authentication in ASP.NET 2.0.
Authorization
You control authorization administratively through URL and file authorization and programmatically by performing identity and role checks in code.
You also need to consider who you are authorizing. Are you authorizing the application, the caller. or both? Also, what are you authorizing access to? You could be authorizing against:
- System resources. These include the file system and registry.
- Application resources. These include business logic and network resources, such as databases and Web services.
- User resources. These include resources such as customer records.
When implementing authorization logic, consider the following guidelines:
- Use URL authorization for page and directory access control.
- Configure ACLs on your Web site files.
- Use ASP.NET role manager for roles authorization.
- If your role lookup is expensive, consider role caching.
- Protect your authorization cookie.
Use URL Authorization for Page and Directory Access Control
Use URL authorization to control which users and groups of users have access to the application or to parts of the application. In ASP.NET version 1.1, URL authorization only applies to file types that are mapped by IIS to the ASP.NET ISAPI extension (Aspnet_isapi.dll). In ASP.NET version 2.0 on Windows Server 2003, URL authorization protects all files in a directory, even files that are not mapped to ASP.NET, such as .html, .gif, and .jpg files.
When your application uses Windows authentication, you can authorize access to Windows user and/or Windows group accounts. To do so, you should configure your application to use ASP.NET Role Manager. For more information, see the "Use ASP.NET Role Manager for Roles Authorization" section in this topic.
You can use the <location> tag to apply authorization settings to an individual file or directory. The following example shows how you can apply authorization to a specific file (page.aspx).
Configure ACLs on Your Web Site Files
You need to configure the right access control lists (ACLs) for the right identities on your Web site files so that IIS and also ASP.NET file authorization control access to these files appropriately. You need to grant access to the following identities:
- Your Web application identity. If you are using a custom service account to run your ASP.NET application, you can grant the appropriate permissions to the IIS metabase and to the file system by running Aspnet_regiis.exe with the–ga switch.
- Your application's users. ASP.NET file authorization performs access checks for file types mapped by IIS to the ASP.NET ISAPI extension (Aspnet_isapi.dll). If you are using Windows authentication, the authenticated user's Windows access token (which may be IUSR_MACHINE for anonymous users) is checked against the ACL attached to the requested ASP.NET file. If you are using forms authentication, access is checked against IUSR_MACHINE.
File authorization works automatically when using Windows authentication, and there is no need to impersonate the original user. The FileAuthorizationModule only performs access checks against the requested file. For example, if you request Default.aspx and it contains an embedded user control (Usercontrol.ascx), which in turn includes an image tag (pointing to Image.gif), the FileAuthorizationModule performs an access check for Default.aspx and Usercontrol.ascx, because these file types are mapped by IIS to the ASP.NET ISAPI extension. The FileAuthorizationModule does not perform a check for Image.gif, because this is a static file handled internally by IIS. However, because access checks for static files are performed by IIS, the authenticated user must still be granted read permission to the file with an appropriately configured ACL.
Use ASP.NET Role Manager for Roles Authorization
In ASP.NET version 1.1, you had to create, manage, and look up roles for the authenticated user by writing your own code. ASP.NET version 2.0 provides a new role manager feature that automatically performs this work. Roles are accessed from the configured role store by the RoleManager HTTP module by using the configured role provider. This occurs after the user is authenticated but before URL authorization and file authorization access checks occur and before programmatic role checks can occur.
If your application needs role-based authorization, use the following guidelines:
If your user accounts are in Active Directory, but you cannot use Windows authentication and must use forms authentication, a good solution for roles management is to use the AuthorizationStoreRoleProvider with an AzMan policy store in ADAM.
Note The AuthorizationStoreRoleProvider does not directly support Authorization Manager business logic such as operations and tasks. To do this, you must use P/Invoke and call the Authorization Manager API directly.
For more information, see How To: Use Role Manager in ASP.NET 2.0.
If Your Role Lookup Is Expensive, Consider Role Caching
If the performance overhead of role lookup is too great, perhaps because of slow data access or a large number of roles, consider caching roles in the roles cookie by setting the cacheRolesInCookie attribute to true in the Web.config file as shown here.
cacheRolesInCookie="true"
... >
When role checks are performed, the roles cookie is checked before calling the role provider to check the list of roles within the data source. This improves performance. The cookie is dynamically updated to cache the most recently validated role names. If the role information for a user is too long to store in a cookie, ASP.NET stores only the most recently used role information in the cookie and then it looks up additional role information in the data source as required. The most recently referred to roles end up being cached in the cookie.
Protect Your Authorization Cookie
You should protect roles data in the authorization cookie to stop users from modifying the list of roles to which they belong, and to stop intruders from gaining information about the roles used by your application. You protect the authorization cookie by appropriately configuring the <roleManager> element as follows:
- Set the cookieProtection attribute to All. This ensures that the role names in the cookie are digitally signed and encrypted to prevent unauthorized viewing and modification of the role data.
- Set the cookieSlidingExpiration attribute to true and the cookieTimeout attribute to an integer number of minutes (for example, 10 to 20 or fewer). The cookie expires when the timeout expires and must be renewed.
- Set the cookieRequireSSL attribute to true to specify that the authorization cookie with the role information should only be returned to the server over HTTPS connections.
- Set the createPersistentCookie attribute to false to ensure that the roles cookie is session-based and not a persistent cookie.
- If you cannot use SSL, consider reducing the cookieTimeout to 10 minutes. If you are concerned with cookie hijacking, consider setting the cookieSlidingExpiration attribute to false. This causes the cookie to expire after the fixed timeout period and must be renewed.
The following example shows a <roleManager> element configured to protect the authorization cookie.
cacheRolesInCookie="true"
cookieName=".ASPROLES"
cookieTimeout="30"
cookiePath="/"
cookieRequireSSL="true"
cookieSlidingExpiration="true"
cookieProtection="All"
createPersistentCookie="false">
Additional Resources
For additional resources on Windows authentication, see the following How Tos:
Code Access Security
Code access security is a resource constraint model designed to restrict the types of system resource that code can access and the types of privileged operation that the code can perform. These restrictions are independent of the user who calls the code or the user account under which the code runs. ASP.NET code access security policy is defined by trust levels.
When using code access security with ASP.NET, consider the following guidelines:
- Consider code access security for partial trust applications.
- Choose a trust level that does not exceed your application's requirements.
- Create a custom trust policy if your application needs additional permissions.
- Use Medium trust in shared hosting environments.
Consider Code Access Security for Partial Trust Applications
If your application calls only managed code, you can use different code access security trust levels to incrementally limit your exposure to security attacks and provide extra degrees of application isolation. You should consider code access security particularly if you need application isolation in shared hosting environments.
If you do not plan on running your application at a partial trust level, code access security presents no additional design or development considerations because at Full trust, code access permission demands will succeed. An application's trust level is determined by the element as shown here.
Choose a Trust Level That Does Not Exceed Your Application's Requirements
Choose a trust level that does not provide additional permissions beyond what your application requires. By doing this, you follow the principle of least privilege and constrain your application as much as possible. To select the most appropriate trust level, identify the precise set of code access security permissions that your application requires. You can do this by manually reviewing your code or by using the Permissions Calculator tool (Permcalc.exe). Evaluate whether the permissions required for your application match those provided by any of the standard trust levels. To see the permissions each trust level provides, examine each trust level policy file in the %windir%\Microsoft.NET\Framework\{version}\CONFIG directory, beginning with the High trust policy file web_hightrust.config.
If your application requires fewer code access security permissions than those provided by the High trust level, move on to consider Medium trust. Repeat the process, moving from Medium to Low to Minimal, and keep evaluating the partial trust levels until you reach an exact match to your application's requirements or until your application's required permissions slightly exceed a partial trust level. If your application needs more permissions than are granted by one level but requires fewer that are provided by the next level, consider creating a custom trust policy.
For more information, see How To: Use Code Access Security in ASP.NET 2.0.
Create a Custom Trust Policy if Your Application Needs Additional Permissions
If your application requires additional permissions beyond those provided at a particular trust level, but it does not need the additional permissions provided by the next trust level, create a custom trust policy file. This avoids granting your application unnecessary permissions.
To create a custom policy, copy the trust level policy file that most closely matches your application's permission requirements to create a new custom policy file. Locate this file in the standard policy file directory, which is %Windir%\Microsoft.NET\Framework\{Version}\CONFIG. Then add the required additional permissions to the custom policy file and configure your application to run using the custom policy.
For more information, see How To: Use Code Access Security in ASP.NET 2.0.
Use Medium Trust in Shared Hosting Environments
In ASP.NET version 1.1, Web applications configured for Medium trust could not access SQL Server databases. In ASP.NET version 2.0, SQL Server database access is available to Medium trust applications because the SQL Server managed data provider no longer demands Full trust. If you need to isolate multiple applications on a shared server from one another and from shared system resources, use Medium trust. To enforce Medium trust for all Web applications on a server, use the following configuration in the machine-level Web.config file.
By setting allowOverride="false", an individual developer is unable to override the Medium trust policy setting in his or her application's Web.config file.
Medium trust provides application isolation because it restricts file system access to the application's own virtual directory hierarchy, and it limits access to HTTP Web resources to a defined address or set of addresses specified by the originUrl attribute on the element. It also prevents access to shared system resources such as the Windows event log and registry. Additionally, Medium trust applications cannot use reflection and cannot access non-SQL Server OLE DB data sources.
For more information, see How To: Use Medium Trust in ASP.NET 2.0.
Data Access
When building the data access layer of your application, consider the following guidelines:
- Encrypt your connection strings.
- Use least-privileged accounts for database access.
- Use Windows authentication where possible.
- If you use Windows authentication, use a trusted service account.
- If you cannot use a domain account, consider mirrored accounts.
- When using SQL authentication, use strong passwords.
- When using SQL authentication, protect credentials over the network.
- When using SQL authentication, protect credentials in configuration files.
- Validate untrusted input passed to your data access methods.
- When constructing SQL queries, use type safe SQL parameters.
- Avoid dynamic queries that accept user input.
Encrypt your connection strings
In ASP.NET version 1.1, you could encrypt connection strings by using DPAPI encryption, although you had to write managed code to wrap the calls to DPAPI. This approach also presented problems in Web farms because of machine affinity. In ASP.NET version 2.0, you can use a protected configuration provider, such as DPAPI or RSA, which is easier to use in Web farms. You do not have to write code because you use the Aspnet_regiis.exe utility.
In ASP.NET version 2.0 applications, place your database connection strings inside the <connectionStrings> element of the Web.config file and then encrypt that element by using the Aspnet_regiis utility. In a Web farm, use the RSA-protected configuration provider because RSA keys can be exported and imported across servers.
For more information, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI and How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.
Use Least-Privileged Accounts for Database Access
Your application should connect to the database by using a least-privileged account. This limits the damage that can be done in the event of a SQL injection attack or in the event of an attacker obtaining your account's credentials. With Windows authentication, use a least-privileged account with limited operating system permissions, and limited ability to access Windows resources. Regardless of authentication mechanism, restrict the account's permissions in the database.
Use the following pattern to limit permissions in the database:
- Create a SQL Server login for the account.
- Map the login to a database user in the required database.
- Place the database user in a database role.
- Grant the database role limited permissions to only those stored procedures or tables that your application needs to access.
Ideally, provide no direct table access and limit access to selected stored procedures only. If you must grant table access, grant the minimum access that the application requires. For example, do not grant update access if read access is sufficient.
By using a database role, you avoid granting permissions directly to the database user. This isolates you from potential changes to the database user name. For example, if you change the database user name, you can simply add the new user to the database role and remove the existing one.
Use Windows Authentication Where Possible
Prefer Windows authentication when connecting to SQL Server or other databases that support it. Windows authentication offers a number of security advantages in comparison to SQL authentication:
- Accounts are centralized and managed by your Active Directory or local authority store.
- Strong password policies can be controlled and enforced by your domain or local security policy.
- Passwords are not transmitted over the network.
- User IDs and passwords are not specified in database connection strings.
For more information, see How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0.
If You Use Windows Authentication, Use a Trusted Service Account
If you use Windows authentication, use a trusted service account to access the database when possible. This is usually your application's process account. By using a single trusted service account, your application benefits from connection pooling; this provides greater scalability. Also, account administration and authorization within the database is simplified. If you need per-user authorization in the database or need to use operating system auditing to track the activity of individual users, you need to use impersonation and delegation and access the database using the caller's identity. This approach has limited scalability because it prevents the efficient use of connection pooling.
If You Cannot Use a Domain Account, Consider Mirrored Accounts
If you cannot use domain accounts because of domain trust or firewall restrictions, consider using mirrored service accounts instead. With this approach, you still use Windows authentication, but you create two local accounts with the same name and password on the Web server and database server. You configure your application to run using the local account created on the Web server and create a SQL login for the local account on the database server. With this approach, you must ensure that the passwords of the two accounts remain in synchronization.
For more information, see How To: Connect to SQL Server Using SQL Authentication in ASP.NET 2.0.
When Using SQL Authentication, Use Strong Passwords
If you use SQL Server authentication, make sure you use a least-privileged account with a strong password to prevent an attacker guessing your account's password. A strong password should be at least seven characters in length and contain a combination of alphabetic, numeric, and special characters.
Avoid using blank passwords and the sa account as shown in the following connection string.
SqlConnectionString = "Server=YourServer\Instance; Database=YourDatabase; uid=sa; pwd=;"
Use least-privileged accounts with a strong password, such as the following.
SqlConnectionString= "Server=YourServer\Instance;
Database=YourDatabase;
uid=YourStrongAccount;
pwd=YourStrongP@ssw0rd;"
When Using SQL Authentication, Protect Credentials Over the Network
If your application is not located in a physically secure isolated data center, you should use Internet Protocol Security (IPSec) or SSL to create an encrypted communication channel between the Web server and database server if your use SQL authentication. Failure to do this means that credentials can be easily captured with a network monitor. When you connect to SQL Server with SQL authentication, the credentials are not encrypted prior to transmission across the network.
Use SSL when you need granular channel protection for a particular application instead of for all applications and services running on a computer. If you want to protect all the IP traffic between Web and database server, use IPSec. You can also use IPSec to restrict which computers can communicate with one another. For example, you can help protect a database server by establishing a policy that permits requests only from a trusted client computer, such as an application or Web server. You can also restrict communication to specific IP protocols and TCP/UDP ports.
When Using SQL Authentication, Protect Credentials in Configuration Files
To protect credentials in configuration files, encrypt them. Place your database connection strings inside the <connectionStrings> element of the Web.config file and then encrypt that element by using the Aspnet_regiis utility. You can use DPAPI or RSA encryption. Use RSA in Web farms because you can easily export and import RSA keys across servers. Protecting connection strings is particularly important for connection strings that use SQL authentication because they contain clear text user IDs and passwords.
Note You should also encrypt connection strings if you use Windows authentication. Although this form of connection string does not contain credentials, you should aim to keep server and database names private.
For more information, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI and How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.
Validate Untrusted Input Passed to Your Data Access Methods
If your data access methods receive input parameters from outside the trust boundary of your data access code, make sure you validate them for type, length, format, and range. You can use regular expressions for text input and perform type and range checks on numeric data. If you do not do this, your data access code is potentially susceptible to SQL injection.
Only omit input parameter validation in your data access methods if you know for certain that data can only be supplied by trusted code, such as your application's business logic, which you know has thoroughly validated the data passed to it.
Note Avoid storing encoded data; instead, encode the data as close as possible to the output.
When Constructing SQL Queries, Use Type Safe SQL Parameters
Use type safe parameters when constructing SQL queries to avoid possible SQL injection attacks that can occur with unfiltered input. You can use type safe parameters with stored procedures and with dynamic SQL statements. Parameters are treated as literal values by the database and not as executable code. Parameters are also checked for type and length.
The following code shows how to use type safe parameters with the SqlParameterCollection when calling a stored procedure.
using System.Data;
using System.Data.SqlClient;
using (SqlConnection connection = new SqlConnection(connectionString))
{
DataSet userDataset = new DataSet();
SqlDataAdapter myCommand = new SqlDataAdapter(LoginStoredProcedure", connection);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;
myCommand.Fill(userDataset);
}
In the preceding code example, the input value cannot be longer than 11 characters. If the data does not conform to the type or length defined by the parameter, the SqlParameter class throws an exception. For more information about preventing SQL injection, see How To: Protect from SQL Injection in ASP.NET.
Avoid Dynamic Queries That Accept User Input
Avoid constructing SQL queries in code that include user input; instead, prefer parameterized store procedures that use type safe SQL parameters. If you construct queries dynamically using user input, your code is susceptible to SQL injection. For example, avoid the following style of code.
// Use dynamic SQL
SqlDataAdapter myCommand = new SqlDataAdapter(
"SELECT au_lname, au_fname FROM authors WHERE au_id = '" +
SSN.Text + "'", myConnection);
If a malicious user supplies "' ; DROP DATABASE pubs --'" for the SSN.Text field, the code inserts the user's malicious input and generates the following query.
SELECT au_lname, au_fname FROM authors WHERE au_id = ''; DROP DATABASE pubs --'
The ; (semicolon) character tells SQL that this is the end of the current statement, which is then followed by the following malicious SQL code, which in this example drops the authors table.
Additional Resources
For additional resources on connecting to SQL Server, see the following How Tos:
Exception Management
Correct exception handling in your Web pages prevents sensitive exception details from being revealed to the user, improves application robustness, and helps avoid leaving your application in an inconsistent state in the event of errors. Consider the following guidelines:
- Use structured exception handling.
- Do not reveal exception details to the client.
- Use a global error handler to catch unhandled exceptions.
Use Structured Exception Handling
Use structured exception handling and catch exception conditions. Doing this improves robustness and avoids leaving your application in an inconsistent state that may lead to information disclosure. It also helps protect your application from denial of service attacks. Use finally blocks to ensure that resources are cleaned up and closed even in the event of an exception condition. Decide how to propagate exceptions internally in your application and give special consideration to what occurs at the application boundary.
Do Not Reveal Exception Details to the Client
When exceptions occur, return concise error messages to the client and log specific details on the server. Do not reveal internal system or application details, such as stack traces, SQL statement fragments, and table or database names to the client. Ensure that this type of information is not allowed to propagate to the end user or beyond your current trust boundary. A malicious user could use system-level diagnostic information to learn about your application and probe for weaknesses to exploit in future attacks.
Prevent detailed error messages from displaying by setting the mode attribute of the <customErrors> element to On, so that all callers receive filtered exception information. Do not use mode="Off" because this allows detailed error pages intended for application developers that contain system-level information to be returned to the client.
You should also use the <customErrors> section of the Web.config file as shown in the following code example to specify a default error page to display, along with other required error pages for specific HTTP response codes that indicate errors.
The defaultRedirect attribute allows you to use a custom error page for your application, which. for example, might include support contact details. Use these application-wide error pages to provide user-friendly responses for errors that are not caught in a structured event handling.
Use a Global Error Handler to Catch Unhandled Exceptions
Define an application-level global error handler in Global.asax to catch any exceptions that are not handled in code. Do this to avoid accidentally returning detailed error information to the client. You should log all exceptions in the event log to record them for tracking and later analysis. Use code similar to the following.
<%@ Application Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
Impersonation/Delegation
By default, ASP.NET Web applications do not impersonate, although in some scenarios, you need to use impersonation to perform operations or access resources using the authenticated user's identity. If you use impersonation, consider the following guidelines:
- Know your tradeoffs with impersonation.
- Avoid calling LogonUser.
- Avoid programmatic impersonation where possible.
- If you need to impersonate, consider threading issues.
- If you need to impersonate, clean up appropriately.
- Avoid losing impersonation tokens.
Know Your Tradeoffs with Impersonation
Be aware that impersonation prevents the efficient use of connection pooling if you access downstream databases by using the impersonated identity. This impacts the ability of your application to scale. Also, using impersonation can introduce other security vulnerabilities, particularly in multi-threaded applications, such as ASP.NET Web applications.
You might need impersonation if you need to:
- Flow the original caller's security context to the middle tier and/or data tier of your Web application to support fine-grained (per-user) authorization.
- Flow the original caller's security context to the downstream tiers to support operating system level auditing.
- Access a particular network resource by using a specific identity.
Avoid Calling LogonUser
Avoid writing code that calls the LogonUser API to create impersonation tokens because this forces you to store user names and passwords on your Web server.
Instead, use a unique application pool with a specific process identity if you need a specific identity to access downstream resources. If you need multiple identities to access a range of downstream resources and services, use Windows Server 2003 protocol transition and the new WindowsIdentity constructor; this allows you to create a Windows token that is given only an account's user principal name (UPN). To access a network resource, you need to delegate-level token. To get this token type, your server needs to be configured as trusted for delegation in Active Directory.
The following code shows how to use this constructor to obtain a Windows token for a given user.
using System;
using System.Security.Principal;
public void ConstructToken(string upn, out WindowsPrincipal p)
{
WindowsIdentity id = new WindowsIdentity(upn);
p = new WindowsPrincipal(id);
}
Note An account's UPN is guaranteed to be unique within a forest. Frequently, the UPN is the user's e-mail address, but it does not have to be. A user always has a UPN and by default, it is userlogonname@fullyqualifieddomainname. If you are logged into a domain, you can find your UPN name by running whoami /upn from a command window.
For more information, see How To: Use Protocol Transition and Constrained Delegation with ASP.NET 2.0.
Avoid Programmatic Impersonation Where Possible
If programmatic impersonation is not done properly, it can introduce security vulnerabilities. It is difficult to get it correct, particularly in multithreaded applications. When possible, use alternative approaches, such as a custom domain process identity for resource access. You should avoid programmatic impersonation where possible for the following reasons:
- It is easy to introduce errors because of thread switches where the thread impersonation token is not propagated across threads.
- Some programmatic techniques require you to store credentials which should be avoided.
- Some programmatic techniques require you to grant additional privileges to your process account, which you should avoid. For example, you must grant your process account "Act as part of the operating system" if you call LogonUser on Windows Server 2000 or to obtain an impersonate-level token on Windows Server 2003 when you use the new WindowsIdentity constructor that generates a token from a user principal name.
- If exceptions occur while impersonating, it is possible for malicious code higher in the call stack to run using the impersonated identity. This can present security issues, particularly if you impersonate a highly privileged account.
If You Need to Impersonate, Consider Threading Issues
Losing an impersonated security context because of thread switches is a common vulnerability. The common language runtime (CLR) automatically propagates impersonation tokens to threads that you create using any of the managed threading techniques, such as Thread.Start, an asynchronous delegate, or QueueUserWorkItem. However, it is easy to drop the thread impersonation token if you use COM interop with components that have incompatible threading models or if you use unmanaged techniques to create new threads such as the Win32 CreateThread API.
If You Need to Impersonate, Clean Up Appropriately
If you must use programmatic impersonation, use structured exception handling and put the impersonation code inside try blocks. Use a catch block to handle exceptions and use a finally block to ensure that the impersonation is reverted as shown here.
using System.Security.Principal;
...
WindowsIdentity winIdentity = new WindowsIdentity("username@domainName");
WindowsImpersonationContext ctx = winIdentity.Impersonate();
try
{
// Do work
}
catch(Exception ex)
{
// Stop impersonating
ctx.Undo();
}
finally
{
// Stop impersonating
ctx.Undo();
}
By using a finally block, you ensure that the impersonation token is removed from the current thread whether an exception is generated or not. Also be aware that if your code fails to catch exceptions, a malicious user could use exception filters to execute code that runs under the impersonated security context. This is particularly serious if your code impersonates a privileged account. If your code does not catch the exception, exception filters higher in the call stack are executed before code in your finally block is executed.
Note Exception filters are supported by Microsoft Intermediate Language (MSIL) and Visual Basic .NET.
For more information, see How To: Use Impersonation and Delegation in ASP.NET 2.0.
Avoid Losing Impersonation Tokens
In .NET Framework 1.1, impersonation tokens did not automatically flow to newly created threads. This situation could lead to security vulnerabilities because new threads assume the security context of the process. In ASP.NET 2.0 applications you can now change this default behavior by configuring the ASPNET.config file in the %Windir%Microsoft.NET\Framework\{Version} directory.
If you need to flow the impersonation token to new threads, set the enabled attribute to true on the alwaysFlowImpersonationPolicy element in the ASPNET.config file, as shown in the following example.
If you need to prevent impersonation tokens from being passed to new threads programmatically, you can use the ExecutionContext.SuppressFlow method.
Parameter Manipulation
Parameters, such as those found in form fields, query strings, view state, and cookies, can be manipulated by attackers who usually intend to gain access to restricted pages or trick the application into performing an unauthorized operation.
The following recommendations help you avoid parameter manipulation vulnerabilities:
- Do not make security decisions based on parameters accessible on the client-side.
- Validate all input parameters.
- Avoid storing sensitive data in ViewState.
- Encrypt ViewState if it must contain sensitive data.
Do Not Make Security Decisions Based on Parameters Accessible on the Client-Side
Do not trust input parameters, especially when they are used to make security decisions at the server. Also, do not use clear text parameters for any form of sensitive data. Instead, store sensitive data on the server in a session store and use a session token to reference the items in the store.
Validate All Input Parameters
Validate all input parameters that come from form fields, query strings, cookies, and HTTP headers. The System.Text.RegularExpressions.Regex class helps validate input parameters. For example, the following code shows how to use this class to validate a name passed through a query string parameter. The same technique can be used to validate other forms of input parameter, such as from cookies or form fields. For example, to validate a cookie parameter, use Request.Cookies instead of Request.QueryString.
using System.Text.RegularExpressions;
...
private void Page_Load(object sender, System.EventArgs e)
{
// Name must contain between 1 and 40 alphanumeric characters
// together with (optionally) special characters such as apostrophes
// for names such as D'Angelo.
if (!Regex.IsMatch(Request.QueryString["name"], @"^[a-zA-Z'`-´\s]{1,40}$"))
throw new Exception("Invalid name parameter");
// Use individual regular expressions to validate all other
// query string parameters.
...
}
For more information, see How To: Protect from Injection Attacks in ASP.NET and How To: Use Regular Expressions to Constrain Input in ASP.NET.
Avoid Storing Sensitive Data in ViewState
Avoid storing sensitive data in ViewState. ViewState is not designed for sensitive data, and protecting it with encryption adds to performance overhead. If you need to manage sensitive data, maintain it on the server; for example, maintain it in session state.
If your ViewState does contain sensitive data, you should consider protecting it against eavesdropping by enabling ViewState encryption as described in the next section.
Encrypt ViewState if It Must Contain Sensitive Data
Using SSL protects ViewState while it is passed over the network between server and browser, but it does not stop it being viewed and modified on the user's computer.
To prevent ViewState from being viewed on the user's computer (and over the network), use ASP.NET ViewState encryption. Do not use it if your ViewState does not contain sensitive data because encryption significantly adds to the size of the ViewState and this impacts performance.
For more information about protecting ViewState, see How To: Configure the Machine Key in ASP.NET 2.0.
Additional Considerations
In addition to the preceding guidelines, consider the following.
- Use Page.ViewStateUserKey to counter one-click attacks.
If you authenticate your callers and use ViewState, set the Page.ViewStateUserKey property in the Page_Init event handler to prevent one-click attacks.
void Page_Init (object sender, EventArgs e) {
ViewStateUserKey = Session.SessionID;
}
Set the property to a value you know is unique to each user, such as a session ID, user name, or user identifier.
A one-click attack occurs when an attacker creates a Web page (.htm or .aspx) that contains a hidden form field named __VIEWSTATE that is already filled with ViewState data. The ViewState can be generated from a page that the attacker had previously created, such as a shopping cart page with 100 items. The attacker lures an unsuspecting user into browsing to the page, and then the attacker causes the page to be sent to the server where the ViewState is valid. The server has no way of knowing that the ViewState originated from the attacker. ViewState validation and HMACs do not counter this attack because the ViewState is valid and the page is executed under the security context of the user.
By setting the ViewStateUserKey property, when the attacker browses to a page to create the ViewState, the property is initialized to his or her name. When the legitimate user submits the page to the server, it is initialized with the attacker's name. As a result, the ViewState HMAC check fails and an exception is generated.
Note This attack is usually not an issue for anonymously browsed pages (where no user name is available), because this type of page should make no sensitive transactions.
Sensitive Data
Sensitive data includes application configuration details (for example, connection strings and service account credentials) and application-specific data (for example, customer credit card numbers). The following recommendations help to reduce risk when you handle sensitive data:
- Avoid plaintext passwords in configuration files.
- Use platform features to manage keys where possible
- Do not pass sensitive data from page to page
- Protect sensitive data over the wire
- Do not cache sensitive data
Avoid Plaintext Passwords in Configuration Files
The <sessionState> and <identity> elements in the Machine.config and Web.config files have userName and password attributes. If you store credentials in these sections, encrypt them by using one of the protected configuration providers.
For more information, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI and How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.
Use Platform Features to Manage Keys Where Possible
Use platform features where possible to avoid managing keys yourself. For example, by using DPAPI, the encryption key is derived from an account's password, so Windows handles this for you.
Do Not Pass Sensitive Data from Page to Page
Avoid using any of the client-side state management options, such as ViewState, cookies, query strings, or hidden form-field variables, to store sensitive data. The data can be tampered with and viewed in clear text. Use server-side state management options, such as a SQL Server database to help protect data exchange.
Protect Sensitive Data Over the Wire
Consider where items of sensitive data, such as credentials and application-specific data, are transmitted over a network link. If you need to send sensitive data between the Web server and browser, consider using SSL. If you need to protect server-to-server communication, such as between your Web server and database, consider IPSec or SSL.
Do Not Cache Sensitive Data
If your page contains data that is sensitive, such as a password, credit card number, or account status, the page should not be cached. Output caching is off by default.
Session Management
There are two main factors that you should consider to help protect session state. First, ensure that the session token cannot be used to gain access to sensitive pages where secure operations are performed or to gain access to sensitive items of data. Second, if the session data contains sensitive items, you must protect the session data, including the session store.
The following recommendations help you build secure session management:
- Do not rely on client-side state management options.
- Protect your out-of-process state service.
- Protect SQL Server session state.
Do Not Rely on Client-Side State Management Options
Avoid using any of the client-side state management options, such as view state, cookies, query strings, or hidden form fields, to store sensitive data. The information can be tampered with or seen in clear text. Use server-side state management options, for example, a database, to store sensitive data.
Protect Your Out-of-Process State Service
If you use mode=StateServer on the <sessionState> element, use the following recommendations to help secure session state:
- Use a least-privileged account to run the state service. By default, the state service runs using the Network Service local, least-privileged account. You should not need to change this configuration
- Protect the channel. If the state service is located on a remote server and you are concerned about the network eavesdropping threat, protect the channel to the remote state store by using IPSec to ensure the user state remains private and unaltered.
- Consider changing the default port. The ASP.NET state service listens on port 42424. To avoid using this default, well-known port, you can change the port by editing the following registry key:
HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters
The port number is defined by the Port named value. If you change the port number in the registry, for example, to 45678, you must also change the connection string on the <sessionState> element, as follows:
stateConnectionString="tcpip=127.0.0.1:45678"
- Encrypt the state connection string. Because this element contains service connection details, you should encrypt it by using one of the protected configuration providers. For more information, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI and How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.
Protect SQL Server Session State
If you use mode="SQLServer" on the <sessionState> element, use the following recommendations to help protect session state:
- Use Windows authentication to the database. This means that passwords are not sent over the network to the database. It also means you do not have to store user names and passwords in the database connection string.
- Encrypt the <sessionState> section. Because this element contains database connection details, you should encrypt it by using one of the protected configuration providers. For more information, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI and How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.
- Limit the application's login in the database. Restrict the login in the database so that it can only be used to access the necessary state tables and the stored procedures used by ASP.NET to query the database. To do this, create a SQL Server login for your ASP.NET process account, and then map the login to a database user in the state store database. Assign the database user to a database role and grant execute permissions for the stored procedures that are provided with the ASPState database.
- Protect the channel. To protect sensitive session state over the network between the Web server and remote state store, protect the channel to the two servers using IPSec or SSL. This provides privacy and integrity for the session state data across the network. If you use SSL, you must install a server certificate on the database server.
Auditing and Logging
You should audit and log activity across the tiers of your application. Using logs, you can detect suspicious-looking activity. This frequently provides early indications of a full-blown attack and the logs help address the repudiation threat where users deny their actions. Log files may be required in legal proceedings to prove the wrongdoing of individuals. Generally, auditing is considered most authoritative if the audits are generated at the precise time of resource access and by the same routines that access the resource.
When implementing auditing and logging in ASP.NET applications:
- Use health monitoring to log and audit events.
- Instrument for user management events.
- Instrument for unusual activity.
- Instrument for significant business operations.
- Consider using an application-specific event source.
- Protect audit and log files.
Use Health Monitoring to Log and Audit Events
ASP.NET version 2.0 introduces a health monitoring feature that you should use to log and audit events. By default, health monitoring is enabled for ASP.NET version 2.0 applications and all Web infrastructure error events (inheriting from System.Web.Management.WebErrorEvent) and all audit failure events (inheriting from System.Web.Management.WebFailureAuditEvent) are written to the event log. The default configuration is defined in the <healthMonitoring> element in the machine-level Web.config file. To audit additional security related events, you create custom event types by deriving from one of the built-in types.
The health monitoring feature has built-in providers that allow you to log events in an e-mail message (SimpleMailWebEventProvider, TemplatedMailWebEventProvider), to SQL Server (SqlWebEventProvider), to the event log (EventLogWebEventProvider), as ASP.NET trace output (TraceWebEventProvider), or to the Windows Management Instrumentation (WMI) Web event provider (WMIWebEventProvider). You can configure health monitoring in the machine or application Web.config file to modify the events that are logged and the way in which they are logged.
For more information, see How To: Use Health Monitoring in ASP.NET 2.0.
Instrument for User Management Events
Instrument your application and monitor user management events such as password resets, password changes, account lockout, user registration, and authentication events. Doing this helps you to detect and react to potentially suspicious behavior. It also enables you to gather operations data; for example, to track who is accessing your application and when user account passwords need to be reset.
By default, ASP.NET health monitoring records all WebFailureAuditEvents, which ASP.NET raises when user authentication fails in forms authentication with the membership system. ASP.NET also raises a WebFailureAuditEvent when authorization is not granted to a resource protected by file authorization and URL authorization.
For more information about auditing password changes and account lockout events, see How To: Instrument ASP.NET 2.0 Applications for Security.
Instrument for Unusual Activity
Instrument your application and monitor events that might indicate unusual or suspicious activity. This enables you to detect and react to potential problems as early as possible. Unusual activity might be indicated by:
- Replays of old authentication tickets.
- To many login attempts over a specific period of time.
Replays of old authentication tickets automatically raise an ExpiredTicketFailure event. To raise an event for too many login attempts, if you are using the membership system and the Login controls, you can write an event handler for the LoginError event of the Login control. In the handler, call Membership.GetUser(Login1.UserName).IsLockedOut to determine if there have been too many login attempts for the user. You can then raise a custom event to indicate that the account has been locked out.
For more information about auditing password changes and account lockout events, see How To: Instrument ASP.NET 2.0 Applications for Security.
Instrument for Significant Business Operations
Use ASP.NET health monitoring to track significant business operations. For example, instrument your application to record access to particularly sensitive methods and business logic. To do this, create a custom event class that inherits from System.Web.Management.WebSuccessAuditEvent or System.Web.Management.WebFailureAuditEvent and raise that event in the appropriate methods. For more information see How To: Instrument ASP.NET 2.0 Applications for Security.
Consider Using an Application-specific Event Source
By default, the EventLogWebEventProvider writes to the application event log by using an event source named "ASP.NET xxxxxx", where xxxxxx is the .NET Framework version number. This is not configurable. If you want events generated by the ASP.NET health monitoring feature to use an application-specific event source, you must create a custom event provider (inherit from EventLogWebEventProvider) and override the ProcessEvent method to write to the event log (by calling EventLog.Write) using the desired event source.
When using a custom event source, you need to create the event source at installation time when administrator privileges are available. If you are unable to create new event sources at installation time, and you are in deployment, the administrator should manually create new event source entry beneath the following registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\
Note You should not grant write permission to the ASP.NET process account (or any impersonated account if your application uses impersonation) on the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\ registry key. If you allow write access to this key and the account is compromised, the attacker can modify any log-related setting, including access control to the log, for any log on the system.
Protect Audit and Log Files
Protect audit and log files using Windows ACLs and restrict access to the log files. If you log events to SQL Server or to some custom event sink, use appropriate access controls to limit access to the event data. For example, grant write access to the account or accounts used by your application, grant full control to administrators, and read-only access to operators.
This makes it more difficult for attackers to tamper with log files to cover their tracks. Minimize the number of individuals who can manipulate the log files. Authorize access only to highly trusted accounts such as administrators.
Additional Considerations
In addition to the preceding guidelines, consider the following measures for auditing and logging:
- Log application events on a separate, protected server. This helps to ensure that logs cannot be tampered by attackers.
- Assign appropriate permissions to the log files. Logs should be written by a process with write permission only. Logs should be read by users with administrative access.
- Log application events with sufficient details. Provide sufficient detail to permit reconstruction of system activity.
- Use performance counters for high volume, per-request events. This helps to minimize the impact on performance.
Deployment Considerations
To avoid introducing vulnerabilities when you deploy your application into a production environment:
- Use a least-privileged account for running ASP.NET applications.
- Encrypt configuration sections that store sensitive data.
- Consider your key storage location.
- Block protected file retrieval by using HttpForbiddenHandler.
- Configure the MachineKey to use the same keys on all servers in a Web farm.
- Lock configuration settings to enforce policy settings.
Use a Least-Privileged Account for Running ASP.NET Applications
On IIS 5, ASP.NET Web applications run by default using the least privileged ASPNET account. On IIS 6, they run inside an application pool using the least privileged Network Service account. If you need to use a custom service account to run your ASP.NET Web application, create a least-privileged account. You might need to create a custom service account to isolate your application from other applications on the same server or to be able to audit each application separately.
To create a least privileged account
- Create a local or domain Windows account.
- Run the following Aspnet_regiis.exe command to assign the relevant ASP.NET permissions to the account:
aspnet_regiis.exe -ga machineName\userName
On Windows Server 2003, running the Aspnet_regiis.exe -ga command will add the account to the IIS_WPG group. The IIS_WPG group provides the Log on as a batch job user right and ensures that the necessary file system permissions are granted.
Note With ASP.NET Beta 2, the Aspnet_regiis.exe–ga command does not add the account to the IIS_WPG group. However, it will do so prior to the final release of ASP.NET 2.0.
- Use the Local Security Policy tool to grant the Windows account the Deny logon locally user right. This reduces the privileges of the account and prevents anyone logging onto Windows locally with the account.
- Use IIS Manager to create an application pool running under the new account's identity and assign your ASP.NET application to the pool.
For more information, see How To: Create a Service Account for an ASP.NET 2.0 Application.
Encrypt Configuration Sections That Store Sensitive Data
In ASP.NET version 1.1, you could use the Aspnet_setreg.exe tool to encrypt certain elements in the Web.config and Machine.config files that contain credentials. This tool replaces the credentials in the configuration file with a pointer to a registry key that holds the DPAPI encrypted data. In ASP.NET version 2.0, you can use either the DPAPI or RSA protected configuration providers to encrypt specific sections that contain sensitive data. The sections that usually contain sensitive information that you need to encrypt include <appSettings>, <connectionStrings>, <identity>, and <sessionState>.
To encrypt the <connectionStrings> section by using the DPAPI provider with the machine-key store (the default configuration), run the following command from a command window:
aspnet_regiis -pe "connectionStrings" -app "/MachineDPAPI" -prov "DataProtectionConfigurationProvider"
- -pe: Specifies the configuration section to encrypt.
- -app: Specifies your Web application's virtual path. If your application is nested, you need to specify the nested path from the root directory; for example, "/test/aspnet/MachineDPAPI".
- -prov: Specifies the provider name.
If you need to encrypt configuration file data on multiple servers in a Web farm, you should use RSA protected configuration provider because of the ease with which you can export RSA key containers. For more information, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI and How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.
Consider Your Key Storage Location
The DPAPI and RSA protected configuration providers used to encrypt sensitive data in configuration files can use either machine stores or user stores for key storage. You can either store the key in the machine store and create an ACL for your specific application identity or store the key in a user store. In the latter case, you need to load the user account's profile to access the key.
Use machine-level key storage when:
- Your application runs on its own dedicated server with no other applications.
- You have multiple applications on the same server that run using the same identity and you want those applications to be able to share sensitive information and the same encryption key.
Use user-level key storage if you run your application in a shared hosting environment and you want to ensure that your application's sensitive data is not accessible to other applications on the server. In this scenario, each application should have a separate identity so they all have their own individual and private key stores.
Block Protected File Retrieval by Using HttpForbiddenHandler
To prevent protected files being downloaded over HTTP, map them to the ASP.NET HttpForbiddenHandler. HTTP handlers are located in the machine-level Web.config file beneath the <httpHandlers> element. HTTP handlers are responsible for processing Web requests for specific file extensions.
Many well-known file extensions are already mapped to System.Web.HttpForbiddenHandler. For .NET Framework resources, if you do not use a particular file extension, map the extension to System.Web.HttpForbiddenHandler in the machine-level Web.config file, as shown here.
This example assumes that your Web server does not host Web services, so the .asmx file extension is mapped to System.Web.HttpForbiddenHandler. If a client requests a path that ends with .asmx, ASP.NET returns a message that says, "This type of page is not served." If your application uses other files with extensions not already mapped, also map these to System.Web.HttpForbiddenHandler.
Configure the MachineKey to Use the Same Keys on All Servers in a Web Farm
If you deploy your application in a Web farm, you must ensure that the configuration files on each server share hashing and encryption keys. These are used by ASP.NET to protect ViewState and forms authentication tickets. Manually generated, common keys are required because you cannot guarantee which server will handle successive requests.
With manually generated key values, the <machineKey> settings should be similar to the following example.
decryptionKey="261F793EB53B761503AC445E0CA28DA44AA9B3CF06263B77"
decryption="3DES"
validation="SHA1" />
For more information about how to manually generate keys, see How To: Configure MachineKey in ASP.NET 2.0.
Lock Configuration Settings to Enforce Policy Settings
To prevent individual application's from being able to override configuration settings with their own Web.config files, apply configuration settings centrally in the machine-level Web.config file located in the following directory: %Windir%\Microsoft.NET\Framework\{version}\CONFIG.
To lock the configuration settings for all Web applications on a Web server, place the configuration settings inside a <system.web> element nested within a <location> element and set the allowOverride attribute to false.
The following example enforces the use of Windows authentication for all Web applications on the server.
If you need to apply and lock settings for a specific Web application, use the path attribute on the <location> element to identify the Web application as shown here.
If you specify the path, it must be fully qualified and include the Web site name and virtual directory name.
Communication Security
When passing sensitive data, such as credentials or application-specific data, across networks, you need to consider the security of the communication channel:
- Consider SSL vs. IPSec.
- Optimize pages that use SSL.
Consider SSL vs. IPSec
If your servers are not inside a physically secure data center where the network eavesdropping threat is considered insignificant, you need to use an encrypted communication channel to protect data sent between servers. SSL and IPSec can both be used to help protect communication between servers by encrypting traffic. Use SSL when you need granular channel protection for a particular application instead of for all applications and services running on a computer.
Use IPSec to help protect the communication channel between two servers and to restrict which computers can communicate with one another. For example, you can help protect a database server by establishing a policy that permits requests only from a trusted client computer such as an application or Web server. You can also restrict communication to specific IP protocols and TCP/UDP ports.
Optimize Pages That Use SSL
Using SSL is expensive. Use SSL only for pages that require it. This includes pages that contain or capture sensitive data, such as pages that accept credit card numbers and passwords. Use SSL only if the following conditions are true:
- You want to encrypt the page data.
- You want to guarantee that the server to which you send the data is the server that you expect.
For pages where you must use SSL, follow these guidelines:
- Make the page size as small as possible.
- Avoid using graphics that have large file sizes. If you use graphics, use graphics that have smaller file sizes and resolution. Or, use graphics from a site that is not secure. However, when you use graphics from a site that is not secure, Web browsers display a dialog box that asks the user if the user wants to display the content from the site that is not secure.
Copy Code