Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of thulek@cz.ibm.com designates
 195.212.29.153 as permitted sender)
In-Reply-To: <d86773480608091806p1c48cb2fjfec737ff21d9494e@mail.gmail.com>
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
To: "Tomcat Users List" <users@tomcat.apache.org>
Message-ID: 
 <OF705A3563.78DFB81A-ONC12571C6.0023EDA2-C12571C6.00256DF9@cz.ibm.com>
From: Tomas Hulek <thulek@cz.ibm.com>
Date: Thu, 10 Aug 2006 08:48:49 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII


Unfortunately, the fundamentally bad security scheme is how the JS API
specification is implemented in Tomcat (when using form-based
authentication).

When processing a form-based authetication request under HTTPS, Tomcat
retains the session ID allocated under HTTP.

We have tried invalidating the session and creating a new one once the user
hits the login form/HTTPS. However, once you invalidate the session in the
login form Tomcat forgets which URL the user wanted to see and tries to
display the "j_security_check", which fails, naturally.

Any hints how to fix it?

Tomas

"Kim Albee" <mtitania@gmail.com> wrote on 10.08.2006 03:06:53:

> It's a fundamentally bad security scheme to use the session-ID as the
> identifier for your users.  Might be straight forward, but
architecturally a
> bad choice if you *really* want a secure area.
>
> Kim :-)
>
> On 8/9/06, Tomas Hulek <thulek@cz.ibm.com> wrote:
> >
> > The default Tomcat installation is prone to session hijacking. I would
> > appreciate help how to fix it.
> >
> > The problem is that the session-id generated under HTTP (eg. for any
JSF
> > page) is caried over to authenticated confidential pages under HTTPS.
> >
> > Thus the session ID can be easily sniffed under HTTP, then misused
after
> > user logs-in under HTTPS.
> >
> > I believe it can be considered as a serious security bug.
> >
> > Scenario:
> >
> > 1) Tomcat and JSF, using Apache MyFaces.
> >
> > 2) A single application (context), using JSF pages
> >
> > 3) Some pages are public, and Faces servlet requests session ID on the
> > first hit
> >
> > 4) Some pages are only accessible under HTTPS after authetication, as
> > defined in web.xml:
> >
> >   <security-constraint>
> >     <web-resource-collection>
> >       <web-resource-name>Secret part</web-resource-name>
> >       <url-pattern>/secret/*</url-pattern>
> >     </web-resource-collection>
> >     <auth-constraint>
> >       <role-name>secret_role</role-name>
> >     </auth-constraint>
> >     <user-data-constraint>
> >       <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> >     </user-data-constraint>
> >   </security-constraint>
> >
> > 5) Form-based authentication is used for the login (again, defined in
> > web.xml).
> >
> > 6) The user goes to the public part of the aplication, gets a session
ID
> > (under HTTP)
> >
> > 7) The user goes to a confidential URL, logging-in successfully. The
same
> > session ID is retained!!!
> >
> > 8) Anyone who knows the session ID generated in step 6 can reach the
> > confidential URL.
> >
> > We have not found any straightforward way of making Tomcat regenerate
the
> > session ID once user swichtes to HTTPS. We tried many approaches, and
all
> > of them break some part of the JSF application.
> >
> >
> > Thank you for your help,
> >
> >
> > Tomas Hulek
> >
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org