Securing Session State

Article
12/04/2014

ASP.NET session state enables you to store and retrieve values for a user as the user navigates the different ASP.NET pages that make up a Web application. ASP.NET session state identifies requests from the same browser during a limited time window as a session and can persist variable values for the duration of that session. Browser sessions are identified in a session cookie or in the URL when session state is configured as "cookieless."

ASP.NET session state is enabled by default for all ASP.NET applications and is configured to use session cookies to identify browser sessions.

ASP.NET session state stores session-variable values in memory by default, but you can also configure session state to store session-variable values in a state server, a SQL Server, or a custom session-state store.

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 with any patches for Microsoft SQL Server, Active Directory, and other data sources for your application.

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 Session-State Configuration

The session-state feature is enabled by default. While the default configuration settings are set to the most secure values, you should disable session state if it is not required for your application. For information about session-state configuration settings and their default values, see sessionState 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 data source connection strings stored in the connectionStrings configuration element. For more information, see Encrypting Configuration Information Using Protected Configuration.

Securing Connections to a Session State Data Source

Connection Strings

As mentioned earlier, it is important to protect the sensitive information stored in a connection string to a computer running SQL Server, the session state service, or another data source. To keep the connection to your data server secure, it is recommended that you 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

You should connect to computers running SQL Server using 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 session-state feature reverts to the identity of the process. You should 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 and Session-State Modes.

Securing the Session ID

When protecting your application and data, it is important that you safeguard the session identifier from being exposed to an unwanted source over the network and being used in a replay attack against your application. The following recommendations can improve the security of your session identifier.

Protect your application with Secure Sockets Layer (SSL).
Specify a smaller value for the session Timeout. Also consider forcing a redirect on the client that is the same length as the session time-out by using a client script, or adding a refresh header by using the AddHeader method as shown in the following example.
```
Response.AddHeader("Refresh", Session.Timeout & ";URL=Logoff.htm"
```
```
Response.AddHeader("Refresh", Session.Timeout + ";URL=Logoff.htm";
```
Avoid using cookieless sessions. If you specify cookieless sessions, warn users not to e-mail, bookmark, or save links that contain a Session ID.
Avoid specifying cookie modes of AutoDetect and UseDeviceProfile.
Allow users to log out, at which point you should call theHttpSessionState.Abandon method. Warn the user to close his or her browser after logging out.
When using cookieless sessions, configure regenerateExpiredSessionID as true to always start a new session when an expired session identifier is supplied.

Secure Web Pages that Use Session State

Application pages that work with sensitive data should be secured using standard Web-security mechanisms, such as using Secure Sockets Layer (SSL) and requiring that users be logged in to carry out sensitive operations like updating personal information or deleting accounts.

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.

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 your 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.

Custom Session-State Store Providers

When creating a custom session-state store 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 session-state store provider, ensure that the provider has been reviewed for security best practices.

Partager via