what is the vulnerability of having Jsessionid on first request only

Jenga Blocks picture Jenga Blocks · Jan 18, 2011 · Viewed 22.6k times · Source

Recently we removed jsessionid from URL did cookies based session management to prevent "session hijacking attack"

But we found that first request URL always has jsessionid when cookies are enabled and subsequent request URL has NO jsessionid.

using the jsessionid from first url we could directly hit other pages in the workflow

Question : is there any security vulnerability exposing jsessionid only on first request?

There is a solution to remove jsessionid from first request , but wanted to check , if its really vulnerable to mandate the changes

thanks J

EDIT : I got my doubt clarified. Thanks for replies.

Answer

Rory McCune picture Rory McCune · Jan 18, 2011

What you've done here could improve the overall security of the solution somewhat, but won't necessarily prevent session hijacking.

the security issue with placing the session ID in the URL is that URLs are exposed in various places (eg, copy and pasted URLs could expose a live session, URLs can be stored in proxy server logs, web server logs and browser history), which could allow an attacker to grab a valid session ID and get access to your users data.

Ideally you should remove the JSESSIONID from the URL in all places, and only use cookie storage.

Additionally if you want to mitiate Session hijacking there's a number of other areas to consider.

You need to use SSL on all pages where the session ID is passed (this is to mitigate the risk of the session ID being intercepted in transit (eg, the Firesheep attack).

If the session ID is set before you authenticate the user, you should ensure that a new session ID is issued when the user logs in.

Also if possible the session cookies should be use of the httpOnly and secure flags, to reduce the risk of them being leaked over cleartext channels.

There's some good additional information on the OWASP Site

BTW if you've got more question on the security side of things, there's a stack exchange site specifically for that at Security.stackexchange.com