tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Richards <>
Subject Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Date Fri, 11 Aug 2006 00:35:27 GMT
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

For example, if your non-secure site is at

and your secure pages are at

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. 


--- Tomas Hulek <> 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>
>     </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:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message