Re: problem with session tracking and redirection http--- https
Henrik Bentel wrote: One of my problems is that I can't find anything in the servlet or tomcat documentation that mentiones any of this behaviour. If there is any, please send me the link. Hi Henrik, I couldn't find anything specific in the Servlet Spec, but in general it's just not a good idea, as you may as well not use https at all. It's not just the servlet spec that you need to be aware of, but this is a more general HTTP/HTTPS problem. RFC2109 is not really clear on the topic, other than section 8.3 which talks about Unexpected Cookie Sharing. However there is an extension to this RFC, RFC2965 Port Sensitive Cookies. Basically, you can't guarantee that the browser is going to send back the cookie if the ports are different Also, since any time session tracking is used it can be picked up by someone, all use of https should stay strictly under https(ok, I'm over doing it). So basically if a webapp has any sensitive information, it should solely use https protocol for all transmissions, if using session tracking? You're not over doing it. If you want to provide some security or protection of authentication then the entire session _must_ be encrypted or you may as well not bother. I don't see why the servlet container should force this behaviour. You can do your own session tracking if you want to. Just set your own cookies and use that. The servlet container provides a very convenient way of doing it. Of course, you'll have the same transition problems that the inbuild session management has. Shouldn't it be up to the developer to determine what is a security issue and not? Just like JSP doesn't neccesseraly force the separation of business logic and content, just allowing it, should the servlet container force a restrictive behaviour of session tracking? A lot of web sites don't want the over head of sending everything over https. Only parts of it for secure user validation. But they still want session tracking. They may do, but they're broken if they don't keep an authentication session safe under ssl. Of course the session tracking can be used at different times for non crucial session tracking. Just as a simple example: So let's say you use the existence of an http session as a validation for a logged in user, but you don't store any vital information. And you only allow http sessions to be created under https protocol to secure the submition of password. Beyond that point, no sensitive data is shared, so users can be redirected back to http protocol. You really need to read up on how HTTP and the servlet spec says sessions are done. Basically HTTP is stateless and sessions are faked by transferring chunks of data between the client and the server. This may be via cookies or URL rewriting. For the sake of convenience, we'll use the cookie method in the example, but this is _not_ necessarily the only way that sessions may be tracked. So, you login securely under username and password admin/secret and those pieces of information are gone and lost forever. However, to maintain the session over the stateless protocol the server sets a cookie in the browser SECRET_COOKIE=aaa56722derf. Now, as you transition to HTTP that piece of information is sent to the server in plain text that anybody can read. So, me being the evil wily hacker grabs that information, and sets a cookie in my evil hacked mozilla browser which will allow me to set arbitrary cookies and bingo, I'm now you. With tomcat 4, the only way to use the same method would be to create a http seesion for every http request, then redirect to https, add some kind of validation flags in the session object, then redirect back. This to me is worse, as a DoS attack could force the servlet container to create a http session for every Request, really putting a strain on your container. I can't possibly think of any circumstance where you would need to perform such a contrived mechanism. In fact, I can't even understand what you're trying to do here. [ snip of rest of post ] -- Jon Eaves [EMAIL PROTECTED] http://www.eaves.org/jon/ -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: problem with session tracking and redirection http--- https
my 2 cents: encrypting session information such as encrypted urls or cookies dont buy anything. they can be sniffed , and sent back. or worse things can happen. Security is not cheap so forget finding an inexpensive way. thats one big problem with open protocols, you know exactly where to get the information and the stucture of information. SSL seems to be the cheapest way of doing business online as of now.
Re: problem with session tracking and redirection http--- https
On Sat, 19 Oct 2002, Henrik Bentel wrote: Date: Sat, 19 Oct 2002 19:08:35 + From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https One of my problems is that I can't find anything in the servlet or tomcat documentation that mentiones any of this behaviour. If there is any, please send me the link. It's not specific to servlets at all ... it's a fundamental issue for anything running across http/https that wants to do the equivalent of sessions. Also, since any time session tracking is used it can be picked up by someone, all use of https should stay strictly under https(ok, I'm over doing it). So basically if a webapp has any sensitive information, it should solely use https protocol for all transmissions, if using session tracking? Not necessarily. Consider an ecommerce site. You'd typically maintain the shopping cart as some sort of collection in a session attribute. You could easily make the case that this information is not particularly sensitive (especially if you haven't collected any personal identification information yet). So, it's quite reasonable to run this part of the app across http. However, once you go to the checkout phase of the app, you should switch to https for the screen that submits the credit card details and that sort of thing, so that nobody can snoop that data as it's being transmitted. However, you are not done yet. Once a particular session has been switched from http to https, it MUST contain logic to never accept a subsequent request (for that session) from http again. Otherwise, your app is subject to attacks like repeatedly submitting the Purchase Confirmation form again, and causing multiple orders to be submitted. I don't see why the servlet container should force this behaviour. Shouldn't it be up to the developer to determine what is a security issue and not? The http-https transition is supported by the servlet spec (and by Tomcat). That's what the transport-guarantee element in a security constraint is for. The https-http transition is not supported because it is fundamentally flawed, and it would be irresponsible for the container to allow naive developers to unknowningly create vulnerable applications. Just like JSP doesn't neccesseraly force the separation of business logic and content, just allowing it, should the servlet container force a restrictive behaviour of session tracking? A lot of web sites don't want the over head of sending everything over https. Only parts of it for secure user validation. But they still want session tracking. Just as a simple example: So let's say you use the existence of an http session as a validation for a logged in user, but you don't store any vital information. And you only allow http sessions to be created under https protocol to secure the submition of password. Beyond that point, no sensitive data is shared, so users can be redirected back to http protocol. No you *cannot* do this safely (from a security perspective). The reason is that the session id *itself* is security sensitive information (because you stored state information in the session that login was successful). Once you switch back into http, the session id is transmitted in clear text, and is subject to hijacking. Anyone on the internet can submit requests using that session id, and the requsts will be executed by your app as if they were submitted by the person who was originally authenticated. Developers who feel that it's sufficient to use https only for the login screen, but want to use http for the rest of the session, are fooling themselves that they have accomplished anything useful (from a security perspective). With tomcat 4, the only way to use the same method would be to create a http seesion for every http request, then redirect to https, add some kind of validation flags in the session object, then redirect back. This to me is worse, as a DoS attack could force the servlet container to create a http session for every Request, really putting a strain on your container. The example probably isn't a good example for how a typical website enforces secure validation, but I just want to raise the point that the hole is still there, since sessions created under http are available in all schemes. It could just as easily be misused by a developer. You are correct that the restriction I'm talking about doesn't deal with DoS attacks based on causing lots of sessions to be created. It deals with a completely different issue. Craig -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: problem with session tracking and redirection http--- https
On Fri, 18 Oct 2002, Maninder S Batth wrote: Date: Fri, 18 Oct 2002 20:11:31 -0700 From: Maninder S Batth [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https if session apis and request dispatchers are used for internal redirection, is there still any security hole?? No, but you can't switch from http to https (or from https to http) across a RequestDispatcher.forward call. The response will be sent on the same protocol used to submit the request. Craig Craig R. McClanahan wrote: On Fri, 18 Oct 2002, Henrik Bentel wrote: Date: Fri, 18 Oct 2002 23:07:17 + From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? Nope ... avoidance of a huge security hole. Once a session is accessed via https, it should never ever be allowed to be accessed from http again. The reason for this is that the session id is transmitted in clear text, so anyone who can snoop the network can hijack your session and impersonate the originally authenticated user (even if that user originally authenticated on an encrypted channel). Do not, under any circumstances, design applications that depend on maintaining session state across an https -- http transition. Craig McClanahan -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: problem with session tracking and redirection http--- https
if session apis and request dispatchers are used for internal redirection, is there still any security hole?? Craig R. McClanahan wrote: On Fri, 18 Oct 2002, Henrik Bentel wrote: Date: Fri, 18 Oct 2002 23:07:17 + From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? Nope ... avoidance of a huge security hole. Once a session is accessed via https, it should never ever be allowed to be accessed from http again. The reason for this is that the session id is transmitted in clear text, so anyone who can snoop the network can hijack your session and impersonate the originally authenticated user (even if that user originally authenticated on an encrypted channel). Do not, under any circumstances, design applications that depend on maintaining session state across an https -- http transition. Craig McClanahan -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
Re: problem with session tracking and redirection http--- https
On Fri, 18 Oct 2002, Maninder S Batth wrote: Date: Fri, 18 Oct 2002 19:28:59 -0700 From: Maninder S Batth [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https please correct me if i am wrong. Session id could be hijacked anytime if it is transmitted as clear text. so once user has loged in , and user gets new session id , this session id could be sniffed and the person can still be impersonated.?? Yes. how is this related to https--http transitiion? If the session was originally established on the https connection, the session id has never been transmitted in the clear, so it cannot be hijacked except when the application accepts a non-https request for that session (or the attacker can impersonate an existing SSL session, in which case we've all got much bigger problems). If the session was originally established under https, but the application switches back to http, the session id is transmitted in the clear from that point on, and is subject to hijacking. This is the logical flaw we discussed earlier this week with regards to a request to accept the login screen on https (to avoid the password being transmitted in the clear) and then switch back to http for the remainder of the session. From the security point of view, this is worse than useless (worse because it gives you a false sense of confidence). Craig Craig R. McClanahan wrote: On Fri, 18 Oct 2002, Henrik Bentel wrote: Date: Fri, 18 Oct 2002 23:07:17 + From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? Nope ... avoidance of a huge security hole. Once a session is accessed via https, it should never ever be allowed to be accessed from http again. The reason for this is that the session id is transmitted in clear text, so anyone who can snoop the network can hijack your session and impersonate the originally authenticated user (even if that user originally authenticated on an encrypted channel). Do not, under any circumstances, design applications that depend on maintaining session state across an https -- http transition. Craig McClanahan -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: problem with session tracking and redirection http--- https
One of my problems is that I can't find anything in the servlet or tomcat documentation that mentiones any of this behaviour. If there is any, please send me the link. Also, since any time session tracking is used it can be picked up by someone, all use of https should stay strictly under https(ok, I'm over doing it). So basically if a webapp has any sensitive information, it should solely use https protocol for all transmissions, if using session tracking? I don't see why the servlet container should force this behaviour. Shouldn't it be up to the developer to determine what is a security issue and not? Just like JSP doesn't neccesseraly force the separation of business logic and content, just allowing it, should the servlet container force a restrictive behaviour of session tracking? A lot of web sites don't want the over head of sending everything over https. Only parts of it for secure user validation. But they still want session tracking. Just as a simple example: So let's say you use the existence of an http session as a validation for a logged in user, but you don't store any vital information. And you only allow http sessions to be created under https protocol to secure the submition of password. Beyond that point, no sensitive data is shared, so users can be redirected back to http protocol. With tomcat 4, the only way to use the same method would be to create a http seesion for every http request, then redirect to https, add some kind of validation flags in the session object, then redirect back. This to me is worse, as a DoS attack could force the servlet container to create a http session for every Request, really putting a strain on your container. The example probably isn't a good example for how a typical website enforces secure validation, but I just want to raise the point that the hole is still there, since sessions created under http are available in all schemes. It could just as easily be misused by a developer. From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Fri, 18 Oct 2002 21:48:36 -0700 (PDT) On Fri, 18 Oct 2002, Maninder S Batth wrote: Date: Fri, 18 Oct 2002 19:28:59 -0700 From: Maninder S Batth [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https please correct me if i am wrong. Session id could be hijacked anytime if it is transmitted as clear text. so once user has loged in , and user gets new session id , this session id could be sniffed and the person can still be impersonated.?? Yes. how is this related to https--http transitiion? If the session was originally established on the https connection, the session id has never been transmitted in the clear, so it cannot be hijacked except when the application accepts a non-https request for that session (or the attacker can impersonate an existing SSL session, in which case we've all got much bigger problems). If the session was originally established under https, but the application switches back to http, the session id is transmitted in the clear from that point on, and is subject to hijacking. This is the logical flaw we discussed earlier this week with regards to a request to accept the login screen on https (to avoid the password being transmitted in the clear) and then switch back to http for the remainder of the session. From the security point of view, this is worse than useless (worse because it gives you a false sense of confidence). Craig Craig R. McClanahan wrote: On Fri, 18 Oct 2002, Henrik Bentel wrote: Date: Fri, 18 Oct 2002 23:07:17 + From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? Nope ... avoidance of a huge security hole. Once a session is accessed via https, it should never ever be allowed to be accessed from http again. The reason for this is that the session id is transmitted in clear text, so anyone who can snoop the network can hijack your session and impersonate the originally authenticated user (even if that user originally authenticated on an encrypted channel). Do not, under any circumstances, design applications that depend on maintaining session state across an https -- http transition. Craig McClanahan -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- Your favorite stores, helpful shopping tools and great gift ideas
Re: problem with session tracking and redirection http--- https
On Thu, 17 Oct 2002, Henrik Bentel wrote: Date: Thu, 17 Oct 2002 04:45:21 + From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. Doing this would be a total waste of time from a security perspective. Nobody needs to see the password if they can see the session id and hijack your session after you've logged on. The only thing hiding the password does is give you a false sense of security. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? My advice would be to not use such applications yourself -- they can clearly be hacked, so they are not trustworthy. -Henrik Craig McClanahan -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: problem with session tracking and redirection http--- https
is the request method changing in redirection, for example post to get ?? if it is, use HttpServletResponse.encodeURL() Henrik Bentel wrote: Another weird behaviour I just discovered is the following: If a httpsession is created by a servlet processing a request sent under(scheme) http, then redirects to https, the session is available to the servlet processing in https. In other words, it stays put. HOWEVER, if a httpsession is created by a servlet processing a request under https, and then redirects to http, the session is not available. But if one redirects back to https agin, the session is available. Also, if you , after redirecting to http(where no session is to be found) create a new session, and then redirect back to https, the original session is lost and the new session created in http scheme is the current one. In tomcat3.3, session created in either schemes(http or https) stays put when redirecting. I haven't found anything in the servlet specification that mentiones anything about this behaviour. From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Thu, 17 Oct 2002 04:45:21 + ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? -Henrik From: Jacob Kjome [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Wed, 16 Oct 2002 23:33:41 -0500 This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org _ Get a speedy connection with MSN Broadband. Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help
Re: problem with session tracking and redirection http--- https
Another weird behaviour I just discovered is the following: If a httpsession is created by a servlet processing a request sent under(scheme) http, then redirects to https, the session is available to the servlet processing in https. In other words, it stays put. HOWEVER, if a httpsession is created by a servlet processing a request under https, and then redirects to http, the session is not available. But if one redirects back to https agin, the session is available. Also, if you , after redirecting to http(where no session is to be found) create a new session, and then redirect back to https, the original session is lost and the new session created in http scheme is the current one. In tomcat3.3, session created in either schemes(http or https) stays put when redirecting. I haven't found anything in the servlet specification that mentiones anything about this behaviour. From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Thu, 17 Oct 2002 04:45:21 + ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? -Henrik From: Jacob Kjome [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Wed, 16 Oct 2002 23:33:41 -0500 This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org _ Get a speedy connection with MSN Broadband. Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: problem with session tracking and redirection http--- https
yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? From: Maninder S Batth [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Fri, 18 Oct 2002 14:13:40 -0700 is the request method changing in redirection, for example post to get ?? if it is, use HttpServletResponse.encodeURL() Henrik Bentel wrote: Another weird behaviour I just discovered is the following: If a httpsession is created by a servlet processing a request sent under(scheme) http, then redirects to https, the session is available to the servlet processing in https. In other words, it stays put. HOWEVER, if a httpsession is created by a servlet processing a request under https, and then redirects to http, the session is not available. But if one redirects back to https agin, the session is available. Also, if you , after redirecting to http(where no session is to be found) create a new session, and then redirect back to https, the original session is lost and the new session created in http scheme is the current one. In tomcat3.3, session created in either schemes(http or https) stays put when redirecting. I haven't found anything in the servlet specification that mentiones anything about this behaviour. From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Thu, 17 Oct 2002 04:45:21 + ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? -Henrik From: Jacob Kjome [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Wed, 16 Oct 2002 23:33:41 -0500 This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail
Re: problem with session tracking and redirection http--- https
This is what i did: 1. use makes https request to tomcat for a jsp page , the jsp page creates a session and adds a variable into session. This jsp page has hyerlink to another ShowVar.jsp but the hyperlink uses http protocol.. 2. i click on the link and ShowVar.jsp displays me the session variable which was created by https jsp. The first file is called PutVar.jsp . It works fine. I am including both the files. Henrik Bentel wrote: yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? From: Maninder S Batth [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Fri, 18 Oct 2002 14:13:40 -0700 is the request method changing in redirection, for example post to get ?? if it is, use HttpServletResponse.encodeURL() Henrik Bentel wrote: Another weird behaviour I just discovered is the following: If a httpsession is created by a servlet processing a request sent under(scheme) http, then redirects to https, the session is available to the servlet processing in https. In other words, it stays put. HOWEVER, if a httpsession is created by a servlet processing a request under https, and then redirects to http, the session is not available. But if one redirects back to https agin, the session is available. Also, if you , after redirecting to http(where no session is to be found) create a new session, and then redirect back to https, the original session is lost and the new session created in http scheme is the current one. In tomcat3.3, session created in either schemes(http or https) stays put when redirecting. I haven't found anything in the servlet specification that mentiones anything about this behaviour. From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Thu, 17 Oct 2002 04:45:21 + ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? -Henrik From: Jacob Kjome [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Wed, 16 Oct 2002 23:33:41 -0500 This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Re: problem with session tracking and redirection http--- https
btw does RequestDispatcher serves your purpose ? Henrik Bentel wrote: yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? From: Maninder S Batth [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Fri, 18 Oct 2002 14:13:40 -0700 is the request method changing in redirection, for example post to get ?? if it is, use HttpServletResponse.encodeURL() Henrik Bentel wrote: Another weird behaviour I just discovered is the following: If a httpsession is created by a servlet processing a request sent under(scheme) http, then redirects to https, the session is available to the servlet processing in https. In other words, it stays put. HOWEVER, if a httpsession is created by a servlet processing a request under https, and then redirects to http, the session is not available. But if one redirects back to https agin, the session is available. Also, if you , after redirecting to http(where no session is to be found) create a new session, and then redirect back to https, the original session is lost and the new session created in http scheme is the current one. In tomcat3.3, session created in either schemes(http or https) stays put when redirecting. I haven't found anything in the servlet specification that mentiones anything about this behaviour. From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Thu, 17 Oct 2002 04:45:21 + ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? -Henrik From: Jacob Kjome [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Wed, 16 Oct 2002 23:33:41 -0500 This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail
Re: problem with session tracking and redirection http--- https
On Fri, 18 Oct 2002, Henrik Bentel wrote: Date: Fri, 18 Oct 2002 23:07:17 + From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? Nope ... avoidance of a huge security hole. Once a session is accessed via https, it should never ever be allowed to be accessed from http again. The reason for this is that the session id is transmitted in clear text, so anyone who can snoop the network can hijack your session and impersonate the originally authenticated user (even if that user originally authenticated on an encrypted channel). Do not, under any circumstances, design applications that depend on maintaining session state across an https -- http transition. Craig McClanahan -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: problem with session tracking and redirection http--- https
please correct me if i am wrong. Session id could be hijacked anytime if it is transmitted as clear text. so once user has loged in , and user gets new session id , this session id could be sniffed and the person can still be impersonated.?? how is this related to https--http transitiion? Craig R. McClanahan wrote: On Fri, 18 Oct 2002, Henrik Bentel wrote: Date: Fri, 18 Oct 2002 23:07:17 + From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? Nope ... avoidance of a huge security hole. Once a session is accessed via https, it should never ever be allowed to be accessed from http again. The reason for this is that the session id is transmitted in clear text, so anyone who can snoop the network can hijack your session and impersonate the originally authenticated user (even if that user originally authenticated on an encrypted channel). Do not, under any circumstances, design applications that depend on maintaining session state across an https -- http transition. Craig McClanahan -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
Re: problem with session tracking and redirection http--- https
This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problem with session tracking and redirection http--- https
ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? -Henrik From: Jacob Kjome [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Wed, 16 Oct 2002 23:33:41 -0500 This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
