HTTP Session Management - JavaEE

Web applications are following HTTP protocol for communication where it instructs how to transport Hyper Text content over a TCP/IP based network environment.

HTTP is known as a state-less protocol where the protocol will NOT provide any functionality to keep track of the messages communicated between client and server over the network.

Server will need to store and process some private data for specific clients connected to the server and the private content will be kept in a volatile memory area within the server which is called a Session. Each session will be able to uniquely identifiable and each have unique ID which is known as SESSIONID. Usually a server keeps single session per client.

Session creation and destruction

When getSession(false) is invoked within the HttpServlerRequest, the servlet will attend to retrieve existing session using the JSESSIONID sent by the client. If existing session is not available it will be NOT create a new session and there will not be generated SESSIONID.

When invoking getSession() or getSession(true) method within HttpServletRequest, it will be first attempt to retrieve existing session as in above getSession(false) scenario. If the session is available, the existing session will be used and existing JSESSIONID will be used. If the session is not existing a NEW session will be created with unique JSESSIONID which is assigned to identify the session.

As HTTP is stateless protocol the server doesn’t have a way of identify whether the user is still consuming the server or not. Hence the sessions on the server are destroyed when each of them are idle than the expiration time which is previously configured within the J2EE application (on web.xml). If the user logout explicitly which is a rare scenario, the session will be destroyed by the application via calling to invalidate() method within the HttpServletRequest.

Securing JSESSIONID

Further for security purposes the JSESSIONID could be encoded to avoid hackers to guess and try to access sessions in the server. There are two types of algorithms used by J2EE containers mostly to make the session ID unique and hard to guess such as;

• PRNG — Pseudo Random Number Generator
• CSPRNG — Cryptographically Secure Pseudo Random Number Generator

PRNG

There are various algorithms to generate random numbers and statistically the number generated should not be able to guess and the next random number could not be able to guess. But in PRNG, the next sequence number could be able to guess.

CSPRNG

These algorithms are generating cryptographically secured pseudo random numbers which are not predictable. And the next generated number is not able to guess by a third party attacker.

Based on the versions of web application servers they are being using different algorithms to generate unique session ids.

In web communication there are two techniques are used to identify which session on server belongs to which client such as;

• URL Rewriting
• Cookies

URL Rewriting

When a client sends a request to the server and if the session is initiated from the J2EE container a JSESSIONID will be generated and it will be assigned to the created new session. And the session ID will be append to the end of the URL where the client is supposed to send the ID back when ever client needs to access data in previously created session.

Cookies

Cookies are piece of data held at the client side to hold values as key-value pairs. Those are used to identify user by the server such as to store JSESSIONID. Cookies are not executable and Mal-ware programs will not be exist in the state of cookies. However a malicious program could extract information stored in cookies if the client computing device is not properly secured for Mal-ware.

There are two types of cookies available such as;

• Session cookie
• Persistence cookie

Session Cookie

This is the default type of cookie and it is only stored within the volatile memory of the web browser. This cookie cannot be used for long term information tracking since it will be destroyed once the browser is closed. Since it retain within browser’s volatile memory, no other application could gain access to the session cookie information unless otherwise in a browser hijacking situation by a hacker. And once user closes the browser all the session cookies lived in there will be destroyed. Usually critical information are held as session cookies within the browsers.

Persistence Cookie

This is set by the server to keep long term information of the user such as single sign on information, track the user behaviour etc. These will not be destroyed once the browser is closed. And if the server needs to expire the persistence cookies it needs to reset with expiration time. And the client could delete its associated persistence cookies using browser functionalities. These cookies are not used to hold critical information since these exist on the user’s persistence storage and any other program could access these information. And the cookies will be stored in a text file such as cookies.txt for Mozilla Firefox.