Session Invalidation

Session is the user's key to the application. Once the user logs out of the application, it is very vital to invalidate the session.

I have come across a situation where the session was not invalidated even when I clicked on the Logout button.

This happened to me with the NetGear Wireless router that I use. I logged into the Router Management page and clicked on the logout button present. I was presented with the logged out screen. All was well till I wanted to visit the Management console again. When I accessed the pages, I was presented with the console without prompting for username/password.

Did I do something wrong? May be. Retry again. But it still shows the same. I use Firefox as the default browser. Then I tried with Internet Explorer. This is where the magic came up.



The logout button sends back to logged out confirmation page and this relies on the java script to close the browser. But that javascript fails in Firefox. There are 2 trivial things here:

1. To rely on the javascript to close the browser and not verifying the cross browser functionality.
2. Not invalidating the session once you click on the Logout button.

Now talking about why it is important to invalidate the session once the user clicks on the logout button:


1. Memory utilization: Most of the times, username is not the only data stored in the Session object. There could be some user specific cache that can be put into the sessions as well. The cache could account to good amount of memory. Imagine thousands of sessions created on the server which are waiting to be cleaned up and the memory they could could be hogging.

2. Security Vulnerability: Well, this is kind of tricky. Lets say the user has clicked on the logout button but the application has not invalidated the session. Now, there is some window between the user clicking on the logout and the session invalidated on the server side due to timeout. Now, lets take a session stealing case. This scenario leads to an extra time window which will help the other guy to use the stolen session and change the system. Invalidating the session once the user has logged out would reduce that security risk.

Session Stealing-2

Contnuation of the previous posting..

My apologies for the abrupt ending of my previous post. Something important came up due to which I had to end it abruptly.

Session hijacking is generally crafted using the following methodologies:

1. Request-Response Sniffing
2. Cross site scripting

Well, the first one can be prevented when the whole session is handled through https. However, if part of the session is handled through http and is switched over to https, then the sniffer would be able to pick up the session id transferred in the http session. To avoid this Pramati Server uses a special cookie in addition to the sessionid cookie. This pair is validated when trying to access the https pages. As the second cookie is set via https, the sniffer would not be able to view it easily. When the sniffer/hijacker sends a https session without the secret cookie, the server would understand that this is not from the authenticated user and hence will deny the response.

Regarding second, you should check if the server is immune to XSS (cross site scripting) vulnerabilities.

Session stealing

You have heard about username/password, identity stealing. Did you ever hear about session stealing/hijacking? Session stealing is the act of taking control of the user session after having obtained/generated authenticated session id. Following is a bit intro on session and session id.

HTTP is stateless protocol. To maintain the state of the logged in users and identify them, the servers depend on the session ids. Session is a series of interactions between two end points( in this case server and client) that happens during the span of single connection. Session ID is a random alphanumeric string that a web server assigns a specific user for the duration of that visit. Once the user is logged into the web site/application a session is created for that user and the server hands out the session id to the browser when sending the first response. The browser would send this Session ID to the server on all the subsequent requests. As long as the user makes the requests from the same browser without closing and reopening it, the web site would not ask for the login information. This is coz,the server/application validates the session id received from the browser and would check if the user with that session id is logged in.

Now that we know what session and session id is let us move on to how it is transmitted between the server and the browser. One of the most used method is to set the session id as cookie on the browser JSESSIONID in case of J2EE and ASPSESSIONID for .NET servers. If you have any tool such as IEHttpHeaders for IE or LiveHttpHeaders for Firefox, you would be able to see something similar to this in the response from the server.

Status=OK - 200

Date=Wed, 27 Jun 2007 11:13:45 GMT

Content-Type=text/html

Set-Cookie=JSESSIONID=978704440835854248; Path=/

X-Cache=MISS from HYD-MDU-CACHE2

Via=1.0 HYD-MDU-CACHE2:515 (squid/2.6.STABLE12)

Connection=close

What you are seeing here is the Session ID Cookie and the value of the session ID. Anyone sniffing on the network packets between your server and you would be able to easily flick this info. Now once he has that session id, he would send the request to the server with the session id along with the request (You can use Tamperdata extenstion of Firefox to do this)

Now you would start thinking. This guy has some random number generated by the server and that is passed between my browser and server. So what? Just to remind you, this session id is not just another alphanumeric string, as far as the application is considered, this your passport to the application unfortunately a passport without photo on it. Any one who has this session id can get the server tricked into believe that it is YOU who is talking to the server. It is equivalent to some one flicking off your passport and presenting himself as you(Remember no photo on it). Now when application believes that some one else is you, then it would allow that person to do what you would be able to do! Let me put it in few steps

1. You open your bank site and go to the login page and login.

2. Once you are successfully logged in, the server would redirect you to your account details and setting a session id cookie in your browser.

3. When you make any request in any of the bank site, the intelligent browser would send the session id to server along with the new request.

4. The server would verify this id and see that you are already logged on. Hence no more login requests.

5. Now lets say there is a guy in the middle who has been sniffing the requests and responses between your machine and the server. He would be able to see the Session ID cookie that’s shared with you. Now he would pick up the same session id and send it over to the server. Since the id is shared between server and only you, the server would be under the impression that you are the one who is talking to server but it is actually not!

6. Now the guy in the middle would make a request for harmless page with your session id sent along to the server.

7. Server would verify the session id and see that you are already logged in and hence would present the harmless page to the guy in between.

8. From here, he would be able to navigate to your account page effortlessly and view details or do what fancies him at that time.

More about this in my next blog.