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: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=tosVHp/+YW7iS1pFe0ZWWHrQBP9k1+q7x8xT7koacFnhkcti2gYaXGhV4oMeEfqNlyChTf/PabT2TtxY6uiKedUWUYa6WGudINgIZ0KQb+nqCeYr+alW+iaIITH+zCAh6w2AokIA+aKdtdbmzBoWgD8957Q8xAsbF+mSMjDSys4=
  ;
Message-ID: <20060811003527.82397.qmail@web50313.mail.yahoo.com>
Date: Thu, 10 Aug 2006 17:35:27 -0700 (PDT)
From: Marc Richards <mjrx20@yahoo.com>
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
To: Tomcat Users List <users@tomcat.apache.org>
In-Reply-To: 
 <OFFBEAD0AC.6F6C0B4A-ONC12571C5.0045874C-C12571C5.00475C47@cz.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Supposing that your secure area is using a constantly
different URL path than your non-secure pages you
could create a filter to modify the default path for
the jsessionid cookie to be valid only for non-secure
pages.

For example, if your non-secure site is at
http://mysite.com/public/...

and your secure pages are at
https://mysite.com/secure/...

You can check the URL path on the request and make
sure the jsessionid cookie is using a similar path
scheme (/public/).  Thus, the session cookie that is
created in the public area will not be sent by the
browser to the secure area (due to differing paths)
and a new session will be created when a secure URL is
requested automatically.

Your filter will then handily modify the new secure
cookie path to be /secure/, which ensures that it will
continue to be sent back with requests to the secure
area.  Also, be sure to set the scheme and secure
attributes on the connector used for secure requests
to "https" and "true" respectively for added security.

This would have the additional benefit of allowing a
user to maintain two sessions simutaneously - one for
the secure area and one for the public area.  I have
done this sort of thing before with success and the
filter is pretty lightweight, so there is little
performance impact. 

-marc


--- 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
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
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