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