RE: Session hijacking with Tomcat/Myfaces - unable to fix it
yeah, I've found that, too, although getRemoteHost theoretically should return the machine name in many cases, but sometimes it won't. -Original Message- From: Maurice Yarrow [mailto:[EMAIL PROTECTED] Sent: Saturday, August 12, 2006 2:45 AM To: Tomcat Users List Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it Hello Barry Generally, getRemoteHost() and getRemoteAddr() return the same value, but I had found a situation during testing where getRemoteAddr() returned an IP address but getRemoteHost() returned nothing. (That was two months ago, and I can't, at this time, remember the exact conditions under which this occurred.) Maurice Yarrow Propes, Barry L wrote: what about getRemoteHost()? -Original Message- From: Maurice Yarrow [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 5:30 PM To: Tomcat Users List Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it 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: [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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
On 8/16/06, Propes, Barry L [EMAIL PROTECTED] wrote: From: Maurice Yarrow [mailto:[EMAIL PROTECTED] Generally, getRemoteHost() and getRemoteAddr() return the same value, but I had found a situation during testing where getRemoteAddr() returned an IP address but getRemoteHost() returned nothing. (That was two months ago, and I can't, at this time, remember the exact conditions under which this occurred.) yeah, I've found that, too, although getRemoteHost theoretically should return the machine name in many cases, but sometimes it won't. It does't always return a host name because getRemoteHost does a reverse DNS lookup on the IP address, which doesn't return a hostname if the DNS servers are either not responding quickly enough or if there was no reverse hostname assigned to the IP address. -Dave - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Hello Barry Generally, getRemoteHost() and getRemoteAddr() return the same value, but I had found a situation during testing where getRemoteAddr() returned an IP address but getRemoteHost() returned nothing. (That was two months ago, and I can't, at this time, remember the exact conditions under which this occurred.) Maurice Yarrow Propes, Barry L wrote: what about getRemoteHost()? -Original Message- From: Maurice Yarrow [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 5:30 PM To: Tomcat Users List Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it 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: [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]
RE: Session hijacking with Tomcat/Myfaces - unable to fix it
what about getRemoteHost()? -Original Message- From: Maurice Yarrow [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 5:30 PM To: Tomcat Users List Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it 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: [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]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
On 8/11/06, Propes, Barry L [EMAIL PROTECTED] wrote: what about getRemoteHost()? getRemoteHost is simply a getRemoteAddr with a reverse DNS lookup thrown on top. No additional security there, in fact one could argue that there is less. -Dave - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session hijacking with Tomcat/Myfaces - unable to fix it
mmm, ok. -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 2:51 PM To: Tomcat Users List Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it On 8/11/06, Propes, Barry L [EMAIL PROTECTED] wrote: what about getRemoteHost()? getRemoteHost is simply a getRemoteAddr with a reverse DNS lookup thrown on top. No additional security there, in fact one could argue that there is less. -Dave - 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]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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-nameSecret part/web-resource-name url-pattern/secret/*/url-pattern /web-resource-collection auth-constraint role-namesecret_role/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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-nameSecret part/web-resource-name url-pattern/secret/*/url-pattern /web-resource-collection auth-constraint role-namesecret_role/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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-nameSecret part/web-resource-name url-pattern/secret/*/url-pattern /web-resource-collection auth-constraint role-namesecret_role/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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!!!
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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 [EMAIL PROTECTED] To Tomcat Users List 10.08.2006 15:09 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 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: [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]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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 [EMAIL PROTECTED] To: Tomcat Users List users@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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] omTo Tomcat Users List 10.08.2006 18:30 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 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 [EMAIL PROTECTED] To: Tomcat Users List users@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: [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]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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 [EMAIL PROTECTED] To: Tomcat Users List users@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 [EMAIL PROTECTED] omTo Tomcat Users List 10.08.2006 18:30 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 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 [EMAIL PROTECTED] To: Tomcat Users List users@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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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: [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]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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 [EMAIL PROTECTED] To: Tomcat Users List users@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 [EMAIL PROTECTED] omTo Tomcat Users List 10.08.2006 18:30 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 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 [EMAIL PROTECTED] To: Tomcat Users List users@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: [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
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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-nameSecret part/web-resource-name url-pattern/secret/*/url-pattern /web-resource-collection auth-constraint role-namesecret_role/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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-nameSecret part/web-resource-name url-pattern/secret/*/url-pattern /web-resource-collection auth-constraint role-namesecret_role/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session hijacking with Tomcat/Myfaces - unable to fix it
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-nameSecret part/web-resource-name url-pattern/secret/*/url-pattern /web-resource-collection auth-constraint role-namesecret_role/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/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]
