Re: PATCH: Session ID from URL; would like some input!
Johan Ström wrote: Hello list! First of all, this maybe better suited for the dev list, but a quick peek only showed svn log mails etc soo.. Sending here instead, let me know if its wrong! It is 50/50. The patch is of more interest to the dev list but if the patch is rejected then the users list is the best place to get ideas about other ways of doing things. The mailing lists block most patches so an enhancement request in Bugzilla is the best place for your patch. Without seeing the patch it is hard to comment but SRV.7.1 makes it clear that cookies override URL parameters. It doesn't make a comment on what if the cookie session is invalid and the URL one not. There might be some scope for flexibility here. We're having a problem related to Tomcat, in a pretty unusual scenario. Basicly the problem is with old expired sessions, and reading session ID from URL instead of cookie. An example, in our case browser A is a main browser, and browser B is a slave browser (actually only a webkit rendering engine) which we only call with an URL to show a specific page, and we do not have control over cookies in browser B. Any way to close browser B? That should delete the session cookie. So, browser B sends both the old session ID in the cookie (which is an expired session), and the new sessionid on the URL. This confuses tomcat. In catalina/connector/Request.java and CoyoteAdaptor, we first check for a sessino ID on the URL, store it in Request, and then we check for a cookie, and if we got one, we just overwrite the session ID from the URL. My solution? The attached patch! Now, what I'd like to know, can anyone of you developers see any nasty side effects that I might have missed about this? In principle, it sounds OK but I'd want to see the patch first. If it were implemented, then it would go into Tomcat 7 and may not be back-ported to earlier versions. It may also be made optional. Keep in mind that session handling is more configurable in the Servlet 3.0 spec (not that I think it helps with this issue) and that changing the session ID on authentication to protect against session fixation is an open enhancement request that should also get included in Tomcat 7. One thing that was concerned about was that it would introduce session hijacking risks, but the only difference is that the evildoer have to erase his (already expired) cookie.. Normal tomcat accepts jsessionid on URL anyway, as long as there is no cookie, so that should not be a security concern. Agreed. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
PATCH: Session ID from URL; would like some input!
Hello list! First of all, this maybe better suited for the dev list, but a quick peek only showed svn log mails etc soo.. Sending here instead, let me know if its wrong! We're having a problem related to Tomcat, in a pretty unusual scenario. Basicly the problem is with old expired sessions, and reading session ID from URL instead of cookie. An example, in our case browser A is a main browser, and browser B is a slave browser (actually only a webkit rendering engine) which we only call with an URL to show a specific page, and we do not have control over cookies in browser B. 1. Browser A goes to our site, gets a new session, authenticates etc. 2. Browser A spawns browser B with url http://example.com/someresource;jsessionid= the session ID from browser A's cookie 3. Browser B loads the page, no session cookie provided since its freshly started, and gets the correct session. Now, lets say both browsers are idle for awhile, enough for the session to timeout 1. Browser A does some activity again, noticing that he got a new JSESSIONID cookie and re-authenticates in the new session. 2. Browser A spawns browser B with an url containing the new jsessionid 3 (this is where the problem is). Browser B loads the page, this time with its old jsessionid cookie, and also the new jsessionid on the URL. So, browser B sends both the old session ID in the cookie (which is an expired session), and the new sessionid on the URL. This confuses tomcat. In catalina/connector/Request.java and CoyoteAdaptor, we first check for a sessino ID on the URL, store it in Request, and then we check for a cookie, and if we got one, we just overwrite the session ID from the URL. My solution? The attached patch! Now, what I'd like to know, can anyone of you developers see any nasty side effects that I might have missed about this? One thing that was concerned about was that it would introduce session hijacking risks, but the only difference is that the evildoer have to erase his (already expired) cookie.. Normal tomcat accepts jsessionid on URL anyway, as long as there is no cookie, so that should not be a security concern.. Well, thanks for any ideas and input, and for Tomcat ofcourse! Best regards Johan Ström Headweb AB - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PATCH: Session ID from URL; would like some input!
Hi Mark, thanks for your response! On Oct 13, 2009, at 10:29 , Mark Thomas wrote: Johan Ström wrote: Hello list! First of all, this maybe better suited for the dev list, but a quick peek only showed svn log mails etc soo.. Sending here instead, let me know if its wrong! It is 50/50. The patch is of more interest to the dev list but if the patch is rejected then the users list is the best place to get ideas about other ways of doing things. The mailing lists block most patches so an enhancement request in Bugzilla is the best place for your patch. I see, it's available here if you'd like to take a quick look: https://dev.headweb.com/johan/pub/Request.java.patch Without seeing the patch it is hard to comment but SRV.7.1 makes it clear that cookies override URL parameters. It doesn't make a comment on what if the cookie session is invalid and the URL one not. There might be some scope for flexibility here. Correct, cookies override URL parameter, but as you said, not when the session in cookie is invalid. I guess one could make it configurable but I have no idea how that would be done, haven't dug that deep into the tomcat source :) We're having a problem related to Tomcat, in a pretty unusual scenario. Basicly the problem is with old expired sessions, and reading session ID from URL instead of cookie. An example, in our case browser A is a main browser, and browser B is a slave browser (actually only a webkit rendering engine) which we only call with an URL to show a specific page, and we do not have control over cookies in browser B. Any way to close browser B? That should delete the session cookie. Unfortunately not, so not a solution. So, browser B sends both the old session ID in the cookie (which is an expired session), and the new sessionid on the URL. This confuses tomcat. In catalina/connector/Request.java and CoyoteAdaptor, we first check for a sessino ID on the URL, store it in Request, and then we check for a cookie, and if we got one, we just overwrite the session ID from the URL. My solution? The attached patch! Now, what I'd like to know, can anyone of you developers see any nasty side effects that I might have missed about this? In principle, it sounds OK but I'd want to see the patch first. If it were implemented, then it would go into Tomcat 7 and may not be back-ported to earlier versions. It may also be made optional. See URL above. Keep in mind that session handling is more configurable in the Servlet 3.0 spec (not that I think it helps with this issue) and that changing the session ID on authentication to protect against session fixation is an open enhancement request that should also get included in Tomcat 7. Me changing the session ID is not what I'm doing, its rather that the old session ID has timed out, and browser A is assigned a new session which i need to tell browser B to use too. One thing that was concerned about was that it would introduce session hijacking risks, but the only difference is that the evildoer have to erase his (already expired) cookie.. Normal tomcat accepts jsessionid on URL anyway, as long as there is no cookie, so that should not be a security concern. Agreed. Great :) Johan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PATCH: Session ID from URL; would like some input!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johan, On 10/13/2009 3:41 AM, Johan Ström wrote: In catalina/connector/Request.java and CoyoteAdaptor, we first check for a sessino ID on the URL, store it in Request, and then we check for a cookie, and if we got one, we just overwrite the session ID from the URL. Is it acceptable to simply disable the use of cookies for your site entirely? Setting Context cookies=false will disable the use of cookies altogether for your site. This would allow you to configure your way out of this problem rather than coding your way out of it (at least, until a more permanent cookie-friendly solution could be reached). Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrU7dYACgkQ9CaO5/Lv0PA9XQCeKV74piFh5XVWvZq9ia4HRBYX EJYAn0IWgYM5iyTUOd2zQozRdu6vlt8S =5fZp -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PATCH: Session ID from URL; would like some input!
On Oct 13, 2009, at 23:15 , Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johan, On 10/13/2009 3:41 AM, Johan Ström wrote: In catalina/connector/Request.java and CoyoteAdaptor, we first check for a sessino ID on the URL, store it in Request, and then we check for a cookie, and if we got one, we just overwrite the session ID from the URL. Is it acceptable to simply disable the use of cookies for your site entirely? Setting Context cookies=false will disable the use of cookies altogether for your site. This would allow you to configure your way out of this problem rather than coding your way out of it (at least, until a more permanent cookie-friendly solution could be reached). I'm afraid not, since the URL loaded is in the same app as the main app, just with a custom view. So as long as its per application, thats not a solution. Anyway, I have tested my patch and I do have my own (now) custom built Tomcat, so using this solution is not a problem. Just wanted to get input from someone more experienced with the tomcat internals before I started more testing/deploying of this! So, thanks for any input :) Johan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
