4

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.

Jenga Blocks
  • 121
  • 1
  • 2
  • 9

3 Answers3

10

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

Rory McCune
  • 1,371
  • 10
  • 17
2

did cookies based session management to prevent "session hijacking attack"

Whats stopping the cookie being hijacked?

Session managment is a server side thing - You need to server to check (based on the cookie) that the user is meant to be logged in.

I don't think you've improved security here at all to be honest, take a look at this excellent article to see why.

m.edmondson
  • 30,382
  • 27
  • 123
  • 206
  • I agree , that cookies can be hijacked. Our requirement was not to expose jsessionid on URL,may be not 100% secure. But having jsessionid our first request URL has any ill effect? Please clarify – Jenga Blocks Jan 18 '11 at 13:31
  • It has no more of an ill effect than using cookies - I would seriously question these requirements – m.edmondson Jan 18 '11 at 13:44
  • Yeah, equally vulnerable . but we will address session hijacking next release . improving overall security was our goal for now. My initial post was bit misleading though – Jenga Blocks Jan 19 '11 at 18:23
  • 3
    No, they are not equally vulnerable. Having the session id in the URL can be a problem even if the site is on SSL. The attacker can create a URL with a predefined session id, and trick the user (via url shortening on twitter etc.) to visit the url. Now the victim gets a session where the session id is known to the attacker. Also URLs are tracked in browser history, proxies etc. Cookies are not. – Erlend Jul 04 '11 at 11:14
  • But cookies are kept by the browser... in fact SSL [also encrypts the URL](http://stackoverflow.com/questions/499591/are-https-urls-encrypted) so I'm not sure your point is valid. It would be surprising if the app provided a session with any ID supplied by the user - this is usually server generated. – m.edmondson Jul 04 '11 at 11:43
  • 3
    @Erlend is describing [session fixation](http://en.wikipedia.org/wiki/Session_fixation). If your app accepts a JSESSIONID in the url and you don't do any additional checking (like verifying ip) then your are vulnerable. The Servlet 3.0 spec has a COOKIE to ensure JSESSIONID is only used as a cookie. The spec even recommends not allowing JSESSIONID in the url. – Patrick Jul 18 '11 at 23:49
0

If someone gets hold of the session id then they pretty much hijack the whole session, see Predictable Session IDs vulnerability.

ismail
  • 46,010
  • 9
  • 86
  • 95