Re: JSESSIONID hijacking
jsessionid is the only way to indentity the user logined. if you get it ,you are this user. but? we can check others , for example IP! - Original Message - From: Pieter Temmerman ptemmerman@sadiel.es To: Tomcat Users List users@tomcat.apache.org Sent: Friday, March 13, 2009 5:15 PM Subject: JSESSIONID hijacking Hi list. I've got an issue which I would like to share with you guys. My webapp requires a user to login, which on his turn creates a session for that user. Now, when I browse my webapp the address bar shows the current URL with a JSESSIONID. Let's say: http://testweb/testpageaction.do;jsessionid=SD23SL4DE134ADFF565D If I execute this same URL in another machine, then I am able to browse my webapp, as if I was logged in. I expected the session to be invalid for this request. I've searched Google for jsessionid hijacking and found some ways to avoid jsessionid to appear in the URL, or at least to ignore jsessionid's passed by URL. However, as the jsessionid URL rewriting is defined in the servlet specification, I would expect this to be secure. Therefor I was wondering whether the hijacking is caused by a misconfiguration of Tomcat, my webapp or rather completely normal. I would really appreciate if someone could shed a light on this. P.S.: I'm using Tomcat 5.5.27 - jdk 1.5.0_15. Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JSESSIONID hijacking
From: Pieter Temmerman [mailto:ptemmerman@sadiel.es] However, as the jsessionid URL rewriting is defined in the servlet specification, I would expect this to be secure. Why, out of interest? Therefor I was wondering whether the hijacking is caused by a misconfiguration of Tomcat, my webapp or rather completely normal. It's completely normal. Other frameworks have exactly the same features. Some form of magic number maps to a session; match the magic number and you match the session. Sometimes there's a different magic number to match a login, but that's just a different magic number that can be hijacked too. If you don't want eavesdroppers to be able to pick up your sessions, use SSL. If you don't want session IDs to appear in your URLs so that your users don't cut+paste them or save them in favourites, use cookies. But be assured that if someone can read the request your browser sends to the server, they can hijack your session. - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JSESSIONID hijacking
However, as the jsessionid URL rewriting is defined in the servlet specification, I would expect this to be secure. Why, out of interest? I don't know. It just seemed way to easy to hijack a session, so I supposed it must be secure. It's completely normal. Other frameworks have exactly the same features. Some form of magic number maps to a session; match the magic number and you match the session. Sometimes there's a different magic number to match a login, but that's just a different magic number that can be hijacked too. If you don't want eavesdroppers to be able to pick up your sessions, use SSL. If you don't want session IDs to appear in your URLs so that your users don't cut+paste them or save them in favourites, use cookies. But be assured that if someone can read the request your browser sends to the server, they can hijack your session. In my case cookies are created as well. By SSL, I suppose you mean client authentication with a certificate? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JSESSIONID hijacking
From: Pieter Temmerman [mailto:ptemmerman@sadiel.es] I don't know. It just seemed way to easy to hijack a session, so I supposed it must be secure. Large portions of the web architecture are insecure by their original design. This makes security in web-based systems... erm.. a challenge :-). In my case cookies are created as well. OK. So why not rely entirely on the cookie rather than exposing the JSESSIONID in the URL at all? Or (most likely) have I got the wrong end of the stick here? By SSL, I suppose you mean client authentication with a certificate? No, I mean securing the connection by using https: rather than http:. Entirely server-side. At least that way, someone with a wiretap can't steal your session IDs off the wire. There's still a long way to go before you can prevent a different person using a different client from using a session ID that they happen to have obtained via (say) an eavesdropping plug-in on the user's browser, but it's a good start. Something to think about: No security will be 100%, not least because there are users involved and they're really remarkably good at leaving massive security holes in any technological solution - emailing their password to a colleague's Hotmail account, writing down login details on a Post-It or just leaving their computer unlocked as they nip to the loo. What security is good enough for your application? - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSESSIONID hijacking
2009/3/13 zhaoxueqing zhaoxueq...@g-data.com.cn: jsessionid is the only way to indentity the user logined. if you get it ,you are this user. but? we can check others , for example IP! But we can *still* do IP spoofing. Any other better recomendation? This issue is one of my concern also. -- Zaki Akhmad - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSESSIONID hijacking
Just a word about associating a given session to one IP address, it works alright and sure is a security enhancement - not sure though if there are built-in support for that in tomcat though it can be implemented at application layer. The major drawback of doing so depends of your user's ISP IPs management i.e. some will change IP addresses quite frequently thus causing them to loose their session each time they'll be switched to a different IP. One would also have to think of network's artefacts such as proxies that may be shared by many users on customer's end - together with your own network architecture that may also prevent you from retrieving correctly originating IPs - re latest posts on request.getRemoteAddr() vs. request.getHeader(REMOTE_ADDR) - Joseph On Fri, Mar 13, 2009 at 12:18 PM, Peter Crowther peter.crowt...@melandra.com wrote: From: Pieter Temmerman [mailto:ptemmerman@sadiel.es] I don't know. It just seemed way to easy to hijack a session, so I supposed it must be secure. Large portions of the web architecture are insecure by their original design. This makes security in web-based systems... erm.. a challenge :-). In my case cookies are created as well. OK. So why not rely entirely on the cookie rather than exposing the JSESSIONID in the URL at all? Or (most likely) have I got the wrong end of the stick here? By SSL, I suppose you mean client authentication with a certificate? No, I mean securing the connection by using https: rather than http:. Entirely server-side. At least that way, someone with a wiretap can't steal your session IDs off the wire. There's still a long way to go before you can prevent a different person using a different client from using a session ID that they happen to have obtained via (say) an eavesdropping plug-in on the user's browser, but it's a good start. Something to think about: No security will be 100%, not least because there are users involved and they're really remarkably good at leaving massive security holes in any technological solution - emailing their password to a colleague's Hotmail account, writing down login details on a Post-It or just leaving their computer unlocked as they nip to the loo. What security is good enough for your application? - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JSESSIONID hijacking
From: Zaki Akhmad [mailto:zakiakh...@gmail.com] 2009/3/13 zhaoxueqing zhaoxueq...@g-data.com.cn: jsessionid is the only way to indentity the user logined. if you get it ,you are this user. but? we can check others , for example IP! Difficult, depending on your environment. Some ISPs run large proxy clusters, meaning that different requests can appear to come from different IP addresses. But we can *still* do IP spoofing. Any other better recomendation? Don't just use a non-varying shared secret (a password) as login information. Instead, use client certificate authentication (distributed by non-network means such as USB keys) and/or a SecurID token or similar. All of which pushes the cost of security to the point that the application may be unworkable. What is good enough for your application? - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSESSIONID hijacking
Pieter Temmerman wrote: Hi list. I've got an issue which I would like to share with you guys. My webapp requires a user to login, which on his turn creates a session for that user. Now, when I browse my webapp the address bar shows the current URL with a JSESSIONID. Let's say: http://testweb/testpageaction.do;jsessionid=SD23SL4DE134ADFF565D If I execute this same URL in another machine, then I am able to browse my webapp, as if I was logged in. I expected the session to be invalid for this request. I've searched Google for jsessionid hijacking and found some ways to avoid jsessionid to appear in the URL, or at least to ignore jsessionid's passed by URL. session ID is passed by URL rewriting or by cookie. Either way is open to sniffers. The only way to avoid sniffers is to use SSL for the entire user session. SSL encrypts the information and also ensures that both sides are talking to whom they expect to talk and not to a man in the middle. However, as the jsessionid URL rewriting is defined in the servlet specification, I would expect this to be secure. Nope. You are assuming away all the problems. Therefor I was wondering whether the hijacking is caused by a misconfiguration of Tomcat, my webapp or rather completely normal. I would really appreciate if someone could shed a light on this. See comments above. You start with SSL, then you should add more layers of security. For example you should ensure that users may only arrive at one of your pages by way of another of your pages. This is sometimes called transaction integrity. I cannot provide info on how we do that without compromising our security, but you should be able to figure out something for your own use. And there are other layers of security to add, logs to review, etc. --cheers, HH P.S.: I'm using Tomcat 5.5.27 - jdk 1.5.0_15. Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org