ASP.NET 2.0 Security Guidelines - Session Management

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan


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