tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: [Proposal] Securely sharing sessions between HTTP and HTTPS
Date Wed, 22 Jan 2003 21:06:27 GMT

One more thing.

Given that in the current version of Tomcat the session id created in
HTTP mode remains the same when switching to HTTPS, then the a
vulnerability similar to that described by Craig is already there. One
does not need to switch from HTTPS to HTTP to create a vulnerability,
*just* switching from HTTP to HTTPS will do it too!

I have actually tried this and was able to hijack the session both in
http and https modes. All I had to know was the JSESSIONID that was
revealed in HTTP mode. Oh, I used the default ports, that is 80 for
HTTP and 443 for HTTPS. It probably does not work otherwise.

Is this an obvious vulnerability or a new one?

One possible fix was already described in my previous message copied

At 19:30 22.01.2003 +0100, you wrote:

>This is a follow up on Craig's message:
> > Consider a scenario where you have "admin" pages that require SSL, and
> > normal pages that can run on either.  Assume Tomcat were modified to
> > migrate your session back.
> >
> > Consider the following course of events:
> >
> > * User A logs on, selects link for an admin function,
> >   and is switched to SSL for that part.
> >
> > * User A then switches back to non-SSL.  Among other things,
> >   this means that the session id is now visible in plaintext
> >   on the wire.
> >
> > * User B snoops the network, acquires the session id,
> >   and submits an SSL request (with the stolen session id)
> >   to an admin function.
> >
> > * Server blithely executes the forged request, because login
> >   identity is attached to the session id (which is now
> >   plaintext -- it wouldn't be if the session had been
> >   created under SSL and never allowed to switch back).
>Craig, thank you for this explanation. It clarifies the rationale for me.
> > Once an application has switched from HTTP to HTTPS for a session, it
> > should be programmed to never go back again.
>I think there is a way to *securely* switch from HTTP to HTTPS and
>vice versa. Here is how.
>Let S be a session shared in both HTTP and HTTPS modes. Furthermore,
>let 'c' be the session identifier of S in HTTP mode and let 't' be
>the session identifier of S in HTTPS mode.
>Thus, 'c' and 't' identify the same session S. If we assume that 'c'
>and 't' are such that by only knowing 'c' it is still impossible or
>excessively hard to guess the value of 't', then revealing 'c' on
>the insecure HTTP channel does not give the attacker an advantage.
>Of course, the servlet container should only honor an HTTPS request
>identified by 't'. It should reject an HTTP request based on 'c'.
>Has the above technique consisting of mapping two session ids to one
>servlet session been previously considered?
>Note the technique is secure because knowing 'c' does not allow the
>attacker to hijack an HTTPS session.
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message