The cookie just contains a session identifier (typically called JSESSIONID). The server maps this identifier to whatever data is currently stored in the user's session.
So when you are creating session, sessionid will be generate by httpsession. and will be store in cookies. You can get this session in request object on Jsp.
also Session management allows a "virtual connection" to be established between browser and servlet so cookies stores the sessionid in it.
Please "correct me if i am wrong.."
Joined: Jul 25, 2012
@Jatan: So if we get session id through cookie than any one who wants to do mischief can use this session id.
Actually, there are 2 different ways to transmit session IDs.
If cookies are enabled, it is sent back and forth with each request/response as a cookie.
If cookies are not enabled, you have to code your webapp to use URL rewriting so that links will contain the session ID as an appendage to their URLs (jsessionid=....). This is a more fragile mechanism than cookies, since any link or direct URL entry lacking the jsessionid appendage will not reference the session, and since HTTP connections are one-shot rather than continuous, your client will not be able to work properly with the server.
The session ID is a synthesized hash key with no inherent meaning in itself and no sensitive information is transmitted. However, it is possible for another user to masquerade as you if they have your current session ID. All that will do is make it as though you were sitting at their computer, however - it won't give you direct access to the internals of the system except to the degree that any user would have such access.
When you switch from clear-text HTTP mode to secure transport (HTTPS), the original session ID is typically discarded and a completely different ID is created. Because transmission is now encrypted, no outside user can obtain that session ID unless they are actively snooping either the server (which hopefully is more secure than that) or your client machine (ditto).
In summary, don't access secure data except via secured URLs and use ONLY HTTPS until you are logged out. Because logging out usually invalidates the session, any secure information would be discarded by the logout process (which also destroys the session ID) and therefore not accessible by anyone making a non-secure impersonation.
An IDE is no substitute for an Intelligent Developer.
Joined: Jul 25, 2012
@Tim that means if anyone gets the sessionid by any mean, can have all privileges of the sessionid until the respective session is destroyed.
Please correct me.
If anyone can provide me any resource where i can understand session in depth with its security aspects.
SessionId is an identifier for the server to identify the incoming request. You can get to know sessionid most of the time either by looking at the browser cookies or in the Url however that doesn't mean you can control that session. There can be alot of other security features associated with the session, one of them being the authenticated user. A lot of times, server issues a unique token which is encrypted in the header to identify the valid user (just an example).
Key here is that session id can only be used by server to retrieve the Httpsession object using session id. Think of a map maintained by a server and whenever any request comes and passes all the security parameter, server uses the session id and retrieve the session object from the map and serves the request.
You can refer to Head First Servlets and JSP to start with. I found it really helpful to understand the basics.