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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
