We have tried it, but the internal session attributes where Tomcat stores
the original request are hidden to application, and are certainly not
accessible to javax.servlet.* API (and we do try to write PORTABLE
application, relying on the specification and not on the internals of one
particular servlet engine).
Commenting on other suggestions
1) SSL for the whole application is not practical, there are many users who
only use the public pages and never log in.
2) We have implemented one workaround in the login-form
if the session was not generated under SSL do the following:
- invalidate session
- create new session and mark it as safe (generated under SSL)
- do an external redirect to a fixed, non-public page
The last step will start the whole login process again, this time with a
safe session ID.
I am still not happy with it. A very enhancement in Tomcat would do:
generate new session ID after switch to HTTPS, based eg. on the SSL session
ID (to get a new, unique ID).
Tomas
David Smith
<[EMAIL PROTECTED]
> To
Tomcat Users List
10.08.2006 13:16 <users@tomcat.apache.org>
cc
Please respond to Subject
"Tomcat Users Re: Session hijacking with
List" Tomcat/Myfaces - unable to fix it
<[EMAIL PROTECTED]
che.org>
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]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
