Session Management
From Dev411: The Code Wiki
Session management keeps track of state through a series of requests known as a session. Session management is often transparent to application developers since it is incorporated in many protocols, however, HTTP is one popular protocol that does not include session management. This makes HTTP lightweight but also requires the web application manage its own session management if it is needed.
| Table of contents |
HTTP/Web Session Management
Since HTTP is stateless, session management is required when web applications wish to keep track of "state" or the status of a series of http requests, typically known as a "session". This can be done through server-side or client-side session management. With either style, each client request needs to be identified by the server which can be done via passive or active client identification.
Best Practices
Server-side session management for sensitive information (i.e. username, authorization roles, expiration date, etc.) and client-side session management for client interactivity (i.e. DHTML) along with active client identification. If your application includes confidential data, encryption should be used to protect that data.
Process Overview
The general steps for session management include:
- Opening the session: When the client makes an HTTP request, the application checks to see if the client has an existing session or not. If the client does not have a session, a session is created, otherwise the existing session is accessed.
- Accessing the session data store to store, retrieve, or change the data in the session object.
- Closing or ending the session.
Server-side Session Management
With server-side session management, the information regarding the session is stored on the server and associated with a session identifier (session id). The session id is a unique value among all current session ids and is typically a random string. The session id is then delivered to the client and sent to the server with each HTTP request. The session id is typically stored in a cookie, form hidden value or as a query string parameter.
Advantages of this method over client-side session management is that the data remains safe on the server and it reduces the amount of traffice sent between the client and the server per request. Server-side session management is good for storing login status, role information, session expiration, etc. Since the session id is stored on the client, session hijacking and eavesdropping can still occur, however, typically this can only happen while the session is active. To prevent this, see the section on encryption.
Client-side Session Management
Client-side session management involves storing session information at the client, typically in cookies. This information is then transmitted to the server each time. Only non-sensitive information should be stored this way because information stored at the client is vulnerable to many attacks including cookie hijacking through cross-site scripting (XSS) attacks.
That being said, client-side session management does have its uses, often when the web client will change state without calling the server such as preliminary form value checking and DHTML effects. While form data verification should always be verified on the server (because client side checking can be overridden/hacked), performing some client-side verification can make for a better user experience.
Active Client Identification
Active client identification involves generating a session id at the server and delivering it to the client. This way the server controls the session id that is used. This method is generally more reliable than passive client identification.
Passive Client Identification
Passive client identification involves using data originating from the client for session management, typically an IP address. This is unreliable for web applications that server the general public and some internal applications as well. Passive identification is discouraged for the following reasons:
- Multi-user operating systems such as Linux and UNIX allow multiple users to log in and run web clients simultaneously with the same IP address.
- Some Internet access providers route requests from their users through a proxy server or NAT where many client computers will appear to have the same IP address. With a series of proxy servers one machine may also appear as many IP addresses as has been observed with people using AOL. Home wireless routers commonly used with DSL and cable modem service often have NAT built-in. This affects single-user operating systems such as Microsoft Windows as well as multi-user operating systems.
- When a client is assigned an IP address through DHCP, the client's IP address can change over the course of a session.
Encryption
Session hijacking and eavesdropping are generally possible with any unencrypted network protocol, be that telnet, FTP or HTTP (internal network or otherwise). Using server-side session management and a single-session session_id on an unencrypted channel will still allow an attacker to hijack and eavesdrop on the session but he typically won't be able to log in again once the session has expired. If a password is placed in a a cookie for client-side session management, the attacker can impersonate the legitimate user at his leisure.
To prevent session hijacking and eavesdropping, encryption is needed. For webservers, this is typically achieved using the HTTPS protocol which encrypts data using SSL. The web server will need to configure your web server for SSL one of the following ways:
- buying a commercial SSL server certificate with a root certificate embedded in most browsers. The majority of users will not see any error prompts and there will be a smooth transition to HTTPS;
- using a free SSL server certificate. The first time the user/browser receives the certificate, the user will be prompted to trust the certificate to view the site. This can be done permanently or for the session only. The dialog box will say something to the effect of certificate not recognized at which time the user will have to click "OK" to trust the certificate; or
- configure the server for anonymous SSL. Not all servers or browsers can handle this.
Once the web server is SSL-enabled, it can be configured to accept only HTTPS traffic or either HTTP or HTTPS traffic. If you are using cookies to store the session id, the secure and domain attributes on the cookies need to be set to ensure they are only sent to the specified servers using HTTPS. Virtually all public commercial web applications that need encryption (e.g. a home banking site) buy a commercial SSL certificate to avoid the a dialog box for their end users.
