Securing Profile Properties

Securing Profile Properties

Switch on low bandwidth view

Collapse All

This page is specific to

Microsoft Visual Studio 2008/.NET Framework 3.5

Other versions are also available for the following:

ASP.NET

Securing Profile Properties

You can use the ASP.NET profile feature to store and retrieve user settings in a data source such as a database. You specify the properties and groups that make up user profiles in the application's configuration file. At run time, ASP.NET uses the configuration information to dynamically generate a class with strongly typed accessors for each profile property. This class is then exposed using the static Profile property. Profile property values are stored by a profile provider in a data source, either in clear-text XML or in serialized binary form.

You can improve the security of your application by following coding and configuration best practices. It is also important that you continually keep your application Web server up to date with the latest security updates for Microsoft Windows and Microsoft Internet Information Services (IIS), as well as with any updates for Microsoft SQL Server or other profile data sources.

For more information about best practices for writing secure code and securing applications, see the book Writing Secure Code by Michael Howard and David LeBlanc and follow the suggestions provided in Microsoft Patterns and Practices (http://www.microsoft.com/resources/practices/default.mspx).

Secure Profile Configuration

The ASP.NET profile feature is enabled by default. Although the default configuration settings are set to the most secure values, we recommend that you disable the user profile feature if it is not required for your application. For information about profile configuration settings and their default values, see profile Element (ASP.NET Settings Schema). Anonymous identification, which can be set for profile properties, is disabled by default. For more information about anonymous identification configuration settings and their default values, see anonymousIdentification Element (ASP.NET Settings Schema).

Securing Configuration Values

When storing sensitive information in a configuration file, we recommend that you encrypt the sensitive values using protected configuration. Information that is especially sensitive includes the encryption keys stored in the machineKey configuration element and connection strings to a data source stored in the connectionStrings configuration element. For more information, see Encrypting Configuration Information Using Protected Configuration.

Securing Connections to a Profile Data Source

Connection Strings

As noted, it is important to protect the sensitive information stored in a connection string that is used to communicate with a computer running SQL Server or another data source. To keep the connection to your database secure, we recommend that you encrypt connection-string information in the configuration using protected configuration. For more information, see Encrypting Configuration Information Using Protected Configuration.

Connecting to SQL Server using Integrated Security

We recommend that you use integrated security to connect to computers running SQL Server, to prevent your connection string from being compromised and any user ID and password information from being exposed. When you specify a connection that uses integrated security to connect to a computer running SQL Server, the profile provider reverts to the identity of the process. We recommend that you ensure that the identity of the process that is running ASP.NET (for example, the application pool) is the default process account or a restricted user account. For more information, see ASP.NET Impersonation.

SQL Server Database Permissions

The SQL Server database that is used by default to store profile information includes database roles and views that enable you to restrict user access to only the privileges required for your application. We recommend that you assign the minimum necessary privileges to the user ID that connects to the SQL Server profile database. For more information, see Roles and Views in the Application Services Database for SQL Server.

Protecting Sensitive Data in the Profile Data Source

The default user profile provider does not encrypt the values stored in the profile data source. We recommend that you encrypt any sensitive information before storing it in the profile data source, to avoid exposing the sensitive information if the data source is compromised. You can encrypt sensitive data before storing the value in the profile property, or you can extend the ProfileBase or ProfileProvider classes to provide encryption capabilities.

Preventing Anonymous Profile Data from Being Shared Across Applications

If anonymous identification is enabled for an application and for profile properties used by that application, there is a risk that the anonymous profile property values can be exposed to another application. This can occur when the anonymous identification cookiePath attribute is set to a path that includes multiple applications and when multiple applications exist in a common domain.

When you use anonymous identification with user profiles and intend to separate anonymous users among applications, we recommend that you specify separate encryption keys in the machineKey element for each application, set the scope of the anonymous-identification cookie to a specific application, and set the ApplicationName property to a different value for each application.

Securing Web Pages that Use Profiles

Application pages that work with sensitive data stored in profile properties should be secured using standard Web-security mechanisms. This includes using Secure Sockets Layer (SSL) and requiring that users be logged on to carry out sensitive operations like updating user information or deleting users. In addition, avoid storing sensitive data in cookies.

Securing Against Denial of Service Attacks

ProfileManager class methods that perform updates or long-running search operations can reduce the responsiveness of your profile data source if the methods are called concurrently by a large number of clients. To reduce your application's exposure to a denial of service attack, permit only administrative users to access ASP.NET pages that perform database updates or searches associated with profiles.

Error Messages and Events

Exceptions

To prevent sensitive information from being exposed, configure your application to not display detailed error messages or to display detailed error messages only when the application is running locally on the Web server. For more information, see the customErrors configuration element.

Event Log

The ASP.NET profile feature logs information for certain error conditions using ASP.NET health monitoring, which by default stores information in the event log. If your server computer is running Windows Server 2003, you can improve the security of your application by securing the event log and by setting event-log parameters regarding the size, retention, and so on to prevent an indirect denial of service attack against the event log.

Trace Information

Your Web server can be configured to trace when certain actions occur regarding the profile feature and to store the trace information in a log file. Because sensitive information such as user names can be stored in the trace log file, we recommend that you allow only administrators to enable tracing, to configure the location of the trace log file, and to access the trace log file.

Custom Profile Providers

When creating a custom profile provider for database access, ensure that you follow security best practices to prevent attacks such as SQL injection attacks. When making use of a custom profile provider, ensure that the provider has been reviewed for security best practices.

Concepts

ASP.NET Profile Properties Overview

Other Resources

Securing ASP.NET Web Sites