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" <[EMAIL PROTECTED]> 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 <[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] > > > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
