You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tomas Hulek <th...@cz.ibm.com> on 2006/08/09 14:59:26 UTC
Session hijacking with Tomcat/Myfaces - unable to fix it
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Mark Thomas <ma...@apache.org>.
Tomas Hulek wrote:
> The default Tomcat installation is prone to session hijacking. I would
> appreciate help how to fix it.
This is a more general http problem with a well known solution. Do
everything over https.
Mark
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Maurice Yarrow <ya...@best.com>.
Hello David, Tomas:
About two months ago, I tried using the getRemoteAddr() for doing IP
check as an addtional auth metric, but found exactly than on local
net, this did not discriminate in many cases and only a single IP
was returned for hosts on LAN. So I decided that there was too
much ambiguity to use this approach, even as addt'l metric.
One could however assume validity of positives but ignore false
negatives, i.e., if IP in conflict with orig, assume man-in-middle
attack, but if IP agrees, must rely on other metrics to determine
possible jeopardy.
Maurice Yarrow
David Rees wrote:
>>> I wonder if associating (and checking) the request IP with the
>>> session would reduce the problem to some acceptable level. What is
>>> the chance of a session being hijacked from the same network
>>> (face-ip)?
>>>
>>> Another question is can the original request IP be spoofed?
>>
>>
>> In this case the chances are relatively high - imagine a company
>> using a proxy to connect to the Internet. The client IP does not
>> change, a someone in the company sniffing can easily hijack sessions
>> from his/her colleagues.
>
>
> Checking the request IP to ensure that it matches the session is a
> good idea, though it doesn't stop all attacks.
>
> If you were to do that, you could also easily add a session attribute
> indicating whether the session was created under http or https and
> invalidate/create a new session if a http session is attempted to be
> used under https.
>
> Besides that, as others suggested, the best thing to do is to simply
> put everything under SSL.
>
> -Dave
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by David Rees <dr...@gmail.com>.
>> I wonder if associating (and checking) the request IP with the
>> session would reduce the problem to some acceptable level. What is
>> the chance of a session being hijacked from the same network
>> (face-ip)?
>>
>> Another question is can the original request IP be spoofed?
>
> In this case the chances are relatively high - imagine a company
> using a proxy to connect to the Internet. The client IP does not
> change, a someone in the company sniffing can easily hijack sessions
> from his/her colleagues.
Checking the request IP to ensure that it matches the session is a
good idea, though it doesn't stop all attacks.
If you were to do that, you could also easily add a session attribute
indicating whether the session was created under http or https and
invalidate/create a new session if a http session is attempted to be
used under https.
Besides that, as others suggested, the best thing to do is to simply
put everything under SSL.
-Dave
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Darryl Miles <da...@netbauds.net>.
Maurice Yarrow wrote:
> Thanks for adding this thought. As per my previous note on this
> subject, in light of your (relative) confidence in using IP, maybe
> I _should_ reconsider the getRemoteAddr() and simply use it as an
> addt'l advisory for making session auth decision on successive
> pages as they transit http/https.
Maybe the information in the "Via:" header should be taken into account
as well. getRemoteAddr() returns the IP address of the last proxy,
there is nothing to stop the proxy route from changing between requests
this is allowed.
Darryl
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Maurice Yarrow <ya...@best.com>.
Long:
Thanks for adding this thought. As per my previous note on this
subject, in light of your (relative) confidence in using IP, maybe
I _should_ reconsider the getRemoteAddr() and simply use it as an
addt'l advisory for making session auth decision on successive
pages as they transit http/https.
Maurice Yarrow
Long wrote:
>I can also imagine this company gives employees the go-a-head and
>hijack each others session. It would also reward the idiot(s) that can
>do it best with double pay...
>
>Your imaginary company example doesn't really happen within a real
>company, does it? Usually there are codes of conduct and policies
>against such malice behavior, with serious consequences. I think
>the risk is rather low than "relatively high", as you say.
>
>Even if you can enforce a "SAFE" session, what is there to stop
>a user from reconstructing his URL (with session ID and all) and
>email it to friends and company?
>
>Session hijacking is a potential problem with all web apps, regardless
>of technology. The only thing we can do, falling short of making the user
>authenticate with each request, is to determine the right balance between
>content security and risk. For most applications, I would feel reasonably
>secure if requests for a session are indeed coming from the same IP.
>
>Long
>
>
>----- Original Message -----
>From: "Tomas Hulek" <th...@cz.ibm.com>
>To: "Tomcat Users List" <us...@tomcat.apache.org>
>Sent: Thursday, August 10, 2006 2:53 PM
>Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
>
>
>
>
>>In this case the chances are relatively high - imagine a company using a
>>proxy to connect to the Internet. The client IP does not change, a someone
>>in the company sniffing can easily hijack sessions from his/her colleagues.
>>
>>Tomas
>>
>>
>>
>> "Long"
>> <long755@rogers.c
>> om> To
>> "Tomcat Users List"
>> 10.08.2006 18:30 <us...@tomcat.apache.org>
>> cc
>>
>> Please respond to Subject
>> "Tomcat Users Re: Session hijacking with
>> List" Tomcat/Myfaces - unable to fix it
>> <users@tomcat.apa
>> che.org>
>>
>>
>>
>>
>>
>>
>>
>>
>>I wonder if associating (and checking) the request IP with the session
>>would reduce the problem to some acceptable level. What is
>>the chance of a session being hijacked from the same network (face-ip)?
>>
>>Another question is can the original request IP be spoofed?
>>
>>Long
>>
>>----- Original Message -----
>>From: "Tomas Hulek" <th...@cz.ibm.com>
>>To: "Tomcat Users List" <us...@tomcat.apache.org>
>>Sent: Thursday, August 10, 2006 12:06 PM
>>Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
>>
>>
>>
>>
>>>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
>>>
>>>
>>>
>>>
>
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Long <lo...@rogers.com>.
I can also imagine this company gives employees the go-a-head and
hijack each others session. It would also reward the idiot(s) that can
do it best with double pay...
Your imaginary company example doesn't really happen within a real
company, does it? Usually there are codes of conduct and policies
against such malice behavior, with serious consequences. I think
the risk is rather low than "relatively high", as you say.
Even if you can enforce a "SAFE" session, what is there to stop
a user from reconstructing his URL (with session ID and all) and
email it to friends and company?
Session hijacking is a potential problem with all web apps, regardless
of technology. The only thing we can do, falling short of making the user
authenticate with each request, is to determine the right balance between
content security and risk. For most applications, I would feel reasonably
secure if requests for a session are indeed coming from the same IP.
Long
----- Original Message -----
From: "Tomas Hulek" <th...@cz.ibm.com>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Thursday, August 10, 2006 2:53 PM
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
>
> In this case the chances are relatively high - imagine a company using a
> proxy to connect to the Internet. The client IP does not change, a someone
> in the company sniffing can easily hijack sessions from his/her colleagues.
>
> Tomas
>
>
>
> "Long"
> <long755@rogers.c
> om> To
> "Tomcat Users List"
> 10.08.2006 18:30 <us...@tomcat.apache.org>
> cc
>
> Please respond to Subject
> "Tomcat Users Re: Session hijacking with
> List" Tomcat/Myfaces - unable to fix it
> <users@tomcat.apa
> che.org>
>
>
>
>
>
>
>
>
> I wonder if associating (and checking) the request IP with the session
> would reduce the problem to some acceptable level. What is
> the chance of a session being hijacked from the same network (face-ip)?
>
> Another question is can the original request IP be spoofed?
>
> Long
>
> ----- Original Message -----
> From: "Tomas Hulek" <th...@cz.ibm.com>
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Sent: Thursday, August 10, 2006 12:06 PM
> Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
>
>
> >
> > 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
> >
> >
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Tomas Hulek <th...@cz.ibm.com>.
In this case the chances are relatively high - imagine a company using a
proxy to connect to the Internet. The client IP does not change, a someone
in the company sniffing can easily hijack sessions from his/her colleagues.
Tomas
"Long"
<long755@rogers.c
om> To
"Tomcat Users List"
10.08.2006 18:30 <us...@tomcat.apache.org>
cc
Please respond to Subject
"Tomcat Users Re: Session hijacking with
List" Tomcat/Myfaces - unable to fix it
<users@tomcat.apa
che.org>
I wonder if associating (and checking) the request IP with the session
would reduce the problem to some acceptable level. What is
the chance of a session being hijacked from the same network (face-ip)?
Another question is can the original request IP be spoofed?
Long
----- Original Message -----
From: "Tomas Hulek" <th...@cz.ibm.com>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Thursday, August 10, 2006 12:06 PM
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
>
> 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
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Long <lo...@rogers.com>.
I wonder if associating (and checking) the request IP with the session
would reduce the problem to some acceptable level. What is
the chance of a session being hijacked from the same network (face-ip)?
Another question is can the original request IP be spoofed?
Long
----- Original Message -----
From: "Tomas Hulek" <th...@cz.ibm.com>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Thursday, August 10, 2006 12:06 PM
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
>
> 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
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Tomas Hulek <th...@cz.ibm.com>.
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
<dns4@cornell.edu
> To
Tomcat Users List
10.08.2006 13:16 <us...@tomcat.apache.org>
cc
Please respond to Subject
"Tomcat Users Re: Session hijacking with
List" Tomcat/Myfaces - unable to fix it
<users@tomcat.apa
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" <mt...@gmail.com> 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 <th...@cz.ibm.com> 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: users-unsubscribe@tomcat.apache.org
>>>For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>
>
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by David Smith <dn...@cornell.edu>.
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" <mt...@gmail.com> 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 <th...@cz.ibm.com> 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: users-unsubscribe@tomcat.apache.org
>>>For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>
>
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Mark Thomas <ma...@apache.org>.
Tomas Hulek wrote:
> Any hints how to fix it?
Again, do all access to your app under https.
Mark
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Tomas Hulek <th...@cz.ibm.com>.
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" <mt...@gmail.com> 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 <th...@cz.ibm.com> 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: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Kim Albee <mt...@gmail.com>.
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 <th...@cz.ibm.com> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Darryl Miles <da...@netbauds.net>.
Tomas Hulek wrote:
> Unfortunately, filters are skipped (ie. not called at all) when form-based
> login page is processed as a result of client requesting a secure area.
>
> We tried that too...
>
> By the way, the original URL that the client requested is hidden in the
> session in a way which prevents the web app from copying it to a new
> session object.
Sorry I was thinking of the general usage case (I dont use Servlet spec
security contraints myself, the mechanisms I use are implemented in
application code). Its straightforward to fix the <security-constaints>
implementation to provide better security since it has access to
internal container code, but...
That still leaves a pure web-app developer out in the cold. Because
there is no mechanism for him to ask the HttpSession object if it has
been exposed to a non-secure channel. Only Tomcat can manage this extra
flag situation effectively because it is container code that is in
charge of session management and emitting the Set-Cookie line, so when
it does that it sets a flag if the connection is not considered a secure
channel.
This is the only missing building block a web-app developer needs to
know to be able to reliably fix the problem from there.
And like I said the client end of the problem is sorted with the
"Secure;" attribute. So the client can be trusted not to leak
information at the wrong time. The problem is that the lack of
mechanism at the server end to do the same.
The cleanest way to implement a solution is to have a
sessionIdHasBeenExposedViaUnsecureChannelFlag and also have a built in
HttpSession.makeSessionSecure();
public HttpSession makeSessionSecure(HttpServletRequest request) {
HttpSession newSession = null;
if(request.getScheme("HTTPS")) { // this might be too crude for
production use in detecting if the request is via a secure channel
// there is no point making the session secure if the request we are
currently on is not secure itself
if(thisSession.hasBeenExposedViaUnsecureChannelFlag()) {
newSession = HttpSession.createNewSession();
newSession.setSecure(true); // turns on the "Secure;" flag
// Ideally we should have a create and setSecure() as one atomic
action ensuring the session never existed for any moment without the
Secure flag set.
// Migrate data
for(Object o : thisSession.getAttributes()) {
newSession.setAttribute(o);
}
// Possibly do internal session management stuff (as necessary)
thisSession.invalidate();
// Possibly do stuff to force new Set-Cookie line in next response
(but I think that happens by default anyway, even through it does not
have to as the client remembers it)
}
}
return newSession;
}
Then the caller just needs to "security prune" the attributes that were
migrated after calling.
You could probably dump the 'request' argument, I was just making the
obvious point that there is no use making a session secure if we're not
already inside a secure channel. But that could be considered
misuse/application programming error.
The actual enforcement of secure channel can then be done easily inside
a regular web-app filter. With a check along the lines of
if(session.hasBeenExposedViaUnsecureChannelFlag()) {
session.invalidate()
}
I agree with the original poster, it is not practically possible to use
HTTPS for everything. The HTTP protocol has a clear mechanism to deal
with this security concern. The culprit here is the lack of
understanding on this issue by the Servlet specification and therefore
Tomcat.
In response to the guy suggesting different path's well the HTTP Cookie
specification allows for this also with the
Path="/ServletContext/secure"; attribute. But going down this avenue
you are placing unnecessary restrictions on a web-application, where as
the approach above does not.
Darryl
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Tomas Hulek <th...@cz.ibm.com>.
Unfortunately, filters are skipped (ie. not called at all) when form-based
login page is processed as a result of client requesting a secure area.
We tried that too...
By the way, the original URL that the client requested is hidden in the
session in a way which prevents the web app from copying it to a new
session object.
Tomas
Darryl Miles
<darryl-mailingli
sts@netbauds.net> To
Tomcat Users List
10.08.2006 15:09 <us...@tomcat.apache.org>
cc
Please respond to Subject
"Tomcat Users Re: Session hijacking with
List" Tomcat/Myfaces - unable to fix it
<users@tomcat.apa
che.org>
Well HTTP Cookies have a solution to this problem. They have a "Secure"
keyword in the Set-Cookie line. This stops the client leaking the
cookie outside of a secure channel.
The problem is I dont think Tomcat keeps track and flags if a session
has been exposed via a non-secure channel or not. If it did then thats
all a web-app filter needs to take action and invalidate the session
itself and pickup a new one (possibly transferring from old HttpSession
to new HttpSession any useful non-security related attributes in the
process).
Darryl
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Darryl Miles <da...@netbauds.net>.
Well HTTP Cookies have a solution to this problem. They have a "Secure"
keyword in the Set-Cookie line. This stops the client leaking the
cookie outside of a secure channel.
The problem is I dont think Tomcat keeps track and flags if a session
has been exposed via a non-secure channel or not. If it did then thats
all a web-app filter needs to take action and invalidate the session
itself and pickup a new one (possibly transferring from old HttpSession
to new HttpSession any useful non-security related attributes in the
process).
Darryl
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Posted by Marc Richards <mj...@yahoo.com>.
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 <th...@cz.ibm.com> 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:
> users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:
> users-help@tomcat.apache.org
>
>
__________________________________________________
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org