Securing Roles
Role management enables you to manage authorization for your application with categories you create, referred to as "roles." By assigning users to roles, you can control access to different parts or features of your Web application based on a role instead of, or in addition to, a user name. For example, an employee application might have roles such as Managers, Employees, Directors, and so on, where different privileges are specified for each role.
Users can belong to more than one role. For example, if your site is a discussion forum, some users might be in the roles of both Members and Moderators. You might define each role to have different privileges on the site, and a user who is in both roles would then have both sets of privileges.
While following coding and configuration best practices can improve the security of your application, it is also important that you continually keep your application server up to date with the latest security patches for Microsoft Windows and Internet Information Services (IIS), as well as any patches for Microsoft SQL Server, Active Directory, or other role data sources.
For more detailed information about best practices for writing secure code and securing applications, see the book "Writing Secure Code" by Michael Howard and David LeBlanc and the guidance provided by Microsoft Patterns and Practices (https://www.microsoft.com/resources/practices/default.mspx).
Secure Role Manager Configuration
The role-manager feature is disabled by default for ASP.NET applications to improve the security of applications that do not use the role manager. When the role-manager feature is enabled, the default configuration settings are set to the most secure values. For information about role-manager configuration settings and their default values, see roleManager Element (ASP.NET Settings Schema).
Securing Configuration Values
When storing sensitive information in a configuration file for an application, you should 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.
Secure Encryption Keys and Hashing
It is highly recommended that you protect role names cached in a cookie by setting the cookieProtection attribute of the roleManager element to All. The encryption key values for the specified encryption algorithm are stored in the machineKey configuration element. For strong encryption, specify an encryption key that is a randomly generated value of the appropriate length for the selected encryption algorithm.
On a server that hosts multiple applications, you should define unique encryption keys for each application. A less secure alternative is to define a single encryption key and specify the IsolateApps option with the key.
Host servers can also restrict the ability to override configuration settings from the machine configuration by denying override rights. This includes denying the ability for encryption keys to be redefined in the Web.config file for an application.
Securing Connections to a Role Data Source
Connection Strings
As mentioned earlier, it is important to protect the connection string that is used to access SQL Server, Active Directory, or another data-source application. To keep the connection to your database server secure, you should encrypt connection-string information in the configuration by using Protected Configuration. For more information, see Encrypting Configuration Information Using Protected Configuration.
Connecting to SQL Server Using Integrated Security
To connect to computers running SQL Server, you should use Integrated Security to avoid the possibility of your connection string being compromised and your user ID and password being exposed. When you specify a connection that uses Integrated Security to connect to a computer running SQL Server, the role-manager feature reverts to the identity of the process. You should ensure that the identity of the process (for example, the application pool) that is running ASP.NET be 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 to store the user information for roles includes database roles and views that enable you to restrict user access to only the required capabilities and visibility. You should assign minimum privileges to the user ID that is used to connect to the SQL Server role database. For more information, see Roles and Views in the Application Services Database for SQL Server.
SQL Server Express Worker Process Identity
SQL Server Express 2005 includes a new mode of operation that allows SQL Server to start a worker process running as the identity of the connecting user. This capability is referred to as "run as user" mode. Although this mode of operation is suitable for desktop development when using IIS, starting worker processes is not appropriate on Web servers hosting multiple, untrusted customer code bases. Shared hosting servers that contain applications that do not trust each other should explicitly disable the "run as user" functionality. This functionality can be turned off by connecting to the SQL Express instance (for example, osql –E –S .\sqlexpress) and issuing the following Transact-SQL command.
EXEC sp_configure 'show advanced option', '1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'user instances enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO
Securing the Authorization Store
To improve the security of your data source when using the AuthorizationStoreRoleProvider, you should store your role information in an Active Directory server, as opposed to a file-based authorization store. This can keep the policy-store file from being exposed should the Web server be compromised.
The role-manager feature reverts to the identity of the process when connecting to an Active Directory server. You should ensure that the identity of the process (for example, the application pool) that is running ASP.NET is the default process account or a restricted user account. For more information, see ASP.NET Impersonation. Additionally, you should assign permissions to the account in the Active Directory authorization store that allow access to only the specific Authorization Manager application or scope required by your ASP.NET application.
You should use a network encryption tool such as Internet Protocol Security (IPSec) to protect the connection to the Active Directory server.
Securing the Role Cookie
You can specify that role names for a user be cached in a session cookie to improve performance by setting the cacheRolesInCookie attribute of the roleManager element to true. By default, the role names are stored in an encrypted format, but you should provide additional security for the roles cookie by setting the cookieRequireSSL attribute to true and only cache roles in a session cookie when SSL is enabled. This keeps the role cookie from being exposed over the network and being used in a replay attack against your application.
Preventing Cookies Being Shared Across Applications
If the cacheRolesInCookie attribute of the roleManager element is set to true, and if the cookiePath attribute is set to a path that includes multiple applications, the same role cookie will be sent to multiple applications. You can share the role cookie across multiple applications by specifying the same encryption information in the machineKey configuration element for each application.
To avoid sharing the role names cookie across multiple applications, specify separate encryption keys in the machineKey configuration element for each application, set the cookiePath attribute for each application to the specific application path, and set the ApplicationName property to a unique value for each application.
Secure Web Pages that Use Roles
Application pages that work with sensitive data, such as logon pages, should be secured using standard Web security mechanisms. These include using Secure Sockets Layer (SSL) and requiring that users be logged on to carry out sensitive operations like updating user information or deleting users.
Additionally, pages should not expose sensitive feature data such as passwords, and in some cases user names, in clear text. Ensure that pages that display such information make use of SSL and are available only to authenticated users. Also, avoid storing sensitive feature data in cookies or sending it across insecure connections.
Securing Against Denial of Service Attacks
Methods that perform updates or large search operations can reduce the responsiveness of your role data source if called concurrently by a number of clients. To reduce your exposure to a denial of service attack, restrict access to ASP.NET pages that make use of methods that perform database updates or searches to administrative users, and expose only ASP.NET pages that provide validation of role membership for general use.
Error Messages and Events
Exceptions
To prevent sensitive information from being exposed to unwanted sources, configure your application either to not display detailed error messages or to display detailed error messages only when the client is the Web server itself. For more information, see customErrors Element (ASP.NET Settings Schema).
Event Log
If your server is running Windows Server 2003, you can improve the security of you application by securing the event log, and by setting parameters regarding the size, retention, and so on of the event log to prevent an indirect denial of service attack against it.
Trace Information
Your Web server can be configured to trace when certain actions occur regarding the role-manager feature and store the trace information in a log file. Because sensitive information such as user names and role names can be stored in the trace log file, you should restrict access to the ability to enable tracing to administrators only as well as the ability to configure the location of the trace log file and access to the trace log file.
Custom Role Providers
When creating a custom role provider, ensure that you follow security best practices to avoid attacks such as SQL injection attacks when working with a database. When making use of a custom role provider, ensure that the provider has been reviewed for security best practices.
Working with Culture-Sensitive Characters
When using the SQL Server role provider or a custom role provider, your data source might be configured to store role data in a culture-sensitive format. However, ASP.NET always evaluates role names specified in the authorization configuration element and role names in the data source as culture invariant. As a result, unauthorized users could be granted unwanted permissions because when their unauthorized role name is treated as culture invariant, it is the same as the name of an authorized role. To avoid users gaining unauthorized access, ensure that role names are unique when evaluated as culture invariant.