Session Identifiers
Browser sessions are identified using a unique identifier stored in the SessionID property. The session ID enables an ASP.NET application to associate a specific browser with related session data and information on the Web server. Session ID values are transmitted between the browser and the Web server in a cookie, or in the URL if cookieless sessions are specified.
.gif "Caution note") Caution |
|---|
P:System.Web.SessionState.HttpSessionState.SessionID values are sent in clear text whether as a cookie or as part of the URL. An unwanted source could gain access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing private or sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID. |
Cookieless SessionIDs
The SessionID is stored in a non-expiring session cookie in the browser by default. You can specify that session identifiers not be stored in a cookie by setting the cookieless attribute to true in the sessionState section of the Web.config file.
.gif "Note") Note |
|---|
To improve the security of your application, you should allow users to log out of your application, at which point the application should call the Abandon method. This reduces the potential for an unwanted source to obtain the unique identifier in the URL and use it to retrieve private user data stored in the session. |
ASP.NET maintains cookieless session state by automatically inserting a unique session ID into the page's URL. For example, the following URL has been modified by ASP.NET to include the unique session ID lit3py55t21z5v55vlm25s55:
http://www.example.com/s(lit3py55t21z5v55vlm25s55)/orderform.aspx
ASP.NET modifies the links contained in all requested pages that use a path relative to the application (explicit paths are not modified) by embedding a session ID value in the links just before sending each page to the browser. Session state is maintained as long as the user follows the path of links that the ASP.NET application provides. However, if the client rewrites a URL supplied by the application, ASP.NET may not be able to resolve the session ID and associate the request with an existing session, resulting in a new session being started for the request.
The session ID is embedded in the URL after the slash that follows the application name and before any remaining file or virtual directory identifier. This allows ASP.NET to resolve the application name before involving the SessionStateModule in the request.
The following example shows a Web.config file that configures an ASP.NET application to use cookieless session identifiers.
<configuration>
<system.web>
<sessionState cookieless="true"
regenerateExpiredSessionId="true" />
</system.web>
</configuration>
Regenerating Expired Session Identifiers
The session ID values used in cookieless sessions are recycled by default. That is, if a request is made with a session ID that has expired, a new session is started using the SessionID supplied with the request. This behavior can result in the unwanted sharing of session data when a link that contains a cookieless SessionID is shared with multiple browsers, perhaps through a search engine or other program. You can reduce the possibility of session data being shared by multiple clients by disabling the recycling of session identifiers. To do this, set the regenerateExpiredSessionId attribute of the sessionState configuration element to true. This will result in a new session ID being generated when a cookieless session request is made with an expired session ID.
| Note |
|---|
If the request made with the expired session ID is made using the HTTP POST method, then any posted data will be lost when regenerateExpiredSessionId is true, as ASP.NET performs a redirect to ensure that the browser has the new session identifier in the URL. |
Custom Session Identifiers
You can implement a custom class to supply and validate SessionID values by creating a class that inherits the SessionIDManager class and overriding the CreateSessionID and Validate methods with your own custom implementations. For an example of overriding the SessionIDManager class and implementing these methods, see the example provided for the CreateSessionID method.
You can replace the entire SessionIDManager by creating a class that implements the ISessionIDManager interface. For example, you may have a Web application that associates a unique identifier with non-ASP.NET pages such as HTML pages or images using an ISAPI filter. You can implement a custom SessionIDManager class to use this unique identifier with ASP.NET session state. If your custom class supports cookieless session identifiers, you will need to implement a solution for sending and retrieving session identifiers in the URL