session id cookie

[Arun kartik Rajendran]

How to mark Session ID Cookie as Secure

[Tim Holloway]

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.

Note, however, that transport security only applies to the network traffic itself. If the secure session ID is misused inside the client app or by code running inside an application object (JavaScript, for example), there is no protection. Therefore for true security is is essential that the client application must be protected against hacking and that any internal mechanisms such as JavaScript are compliant with their sandbox limitations.

[Arun kartik Rajendran]

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.

Please give any idea about this...

[Tim Holloway]

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.

[Arun kartik Rajendran]

Thanks I got it clearly....