You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Pieter Temmerman <pt...@sadiel.es> on 2009/03/13 10:15:00 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JSESSIONID hijacking
Posted by "H. Hall" <hh...@reedyriver.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JSESSIONID hijacking
Posted by Joseph Millet <jo...@gmail.com>.
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
<Pe...@melandra.com> wrote:
>> From: Pieter Temmerman [mailto:ptemmerman.ext@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JSESSIONID hijacking
Posted by Peter Crowther <Pe...@melandra.com>.
> From: Pieter Temmerman [mailto:ptemmerman.ext@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JSESSIONID hijacking
Posted by Pieter Temmerman <pt...@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?
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JSESSIONID hijacking
Posted by Peter Crowther <Pe...@melandra.com>.
> From: Pieter Temmerman [mailto:ptemmerman.ext@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JSESSIONID hijacking
Posted by Peter Crowther <Pe...@melandra.com>.
> From: Zaki Akhmad [mailto:zakiakhmad@gmail.com]
> 2009/3/13 zhaoxueqing <zh...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JSESSIONID hijacking
Posted by Zaki Akhmad <za...@gmail.com>.
2009/3/13 zhaoxueqing <zh...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JSESSIONID hijacking
Posted by zhaoxueqing <zh...@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!
----- Original Message -----
From: "Pieter Temmerman" <pt...@sadiel.es>
To: "Tomcat Users List" <us...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>