The session ID is a hash key with no inherent meaning. It is assigned by the appserver, and only the appserver knows how to use that key to access the session objects.
If you are using non-secure protocol (HTTP), the session ID is visible to anyone who monitors the communications between client and server. Although the session ID is not directly usable, it could then be employed to inject attack requests to the server and perform unauthorized operations.
When you switch from non-secure (HTTP) to secure (HTTPS) protocols, typically the old session ID is destroyed an a new session ID is assigned so that the old session ID cannot be used to tap into session objects once transport is secured. Because this new session ID is only transmitted/received in encrypted form it cannot be exploited.
An IDE is no substitute for an Intelligent Developer.
Arun kartik Rajendran
Joined: Feb 28, 2013
Thank you for the clear explanation
I am using HTTPS protocol only but still I can able to view my session Id as a clear text, means session Id is not encrypted.
HTTPS means that data travelling on the network is encrypted. Data on the client or on the server is not.
It doesn't really matter if the session ID is encrypted in the client, since the session ID has no meaning other than as a key to be referenced by the server for associating a specific user with a specific request. Well, behaved authorized programs are going to be using it anyway, and one string of random (non-encrypted) characters is as good as another string of random (encrypted) characters for that purposes.
Rogue software on the client, on the other hand, has generally exploited the client machine at a higher level, so the fact that it can get at session IDs is mostly worrying about the barn door latch after the horse was already stolen. An exception to that is the CSRF exploit, but that requires that an additional token be supplied to the client.