Right. Tomcat stores the original request info in the session before
redirecting to the login page. Invalidate the session and the original
request url is gone.
You could try (and I haven't tried this) is to find the original request
info stored in the old session, pull it out of the old session,
invalidate the old session, and then put that info into your new session.
Just throwing out an idea for you...
--David
Tomas Hulek wrote:
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]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
