Re: How to avoid session fixation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, david delbecq wrote: | I would more be thinking about applications that plays with | sessionlistener and maintain list of active session (to track number of | users / who is logged in, etc). Like ip<->session id matching, a change | id on the fly could also break at several levels and should be | optional. Agreed. | Also, for example, of non-cookies enabled user, for which url | previous to login would become useless (or at least would point to a | non-existent session). True, but I would think that anyone sufficiently concerned about this particular issue would make arrangements for that possibility if they were going to employ a session-switcher thing. This is a problem whether you change the session id directly or change the session (and get a new id). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkexqPsACgkQ9CaO5/Lv0PBxbwCfehX9F9KxPs8tK7gJCgh3ctww nRYAn0Basg+wi6imjK5aFqjQE1f0BAOL =85D4 -END PGP SIGNATURE- - 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: How to avoid session fixation?
Christopher Schultz a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, David Delbecq wrote: | I think this is worth submitting a security issue request on tracker, | to ask that, at least, the container links the requester IP to the | session. I'm pretty sure that nobody will want to do this -- at least not without the ability to turn the feature off. You'll break a lot of users if you This won't be the first fix in tomcat that would potentially break other application, in the past tomcat team have always made such change optionnal. IT wold anywa be good for system administrator if they can prevent such issue. | Changing session ID upon login in container would be a good thing | imho, it would ensure ID become unknown to attacker after login, | wouldn't destroy user session (keep session, only change it's | identifier) and would work whatever authentication mechanism is used. | I completely agree. Christopher, I think your valve might be more attractive if it was able to change the id of the session and leave it at that. I'm not familiar enough with the Tomcat API to know if this is possible and/or a good idea. | Draw back is that webapp that rely on session id for some session | tracking mechanism would break. True, although most webapps probably use whatever session id is currently in use. If you did a lot of AJAX where the session id available to the page becomes out-of-date after a login, you will have to make special considerations for that. I think you'll find that this is not much of a problem. I would more be thinking about applications that plays with sessionlistener and maintain list of active session (to track number of users / who is logged in, etc). Like ip<->session id matching, a change id on the fly could also break at several levels and should be optional.Also, for example, of non-cookies enabled user, for which url previous to login would become useless (or at least would point to an inexistant session). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkewsO8ACgkQ9CaO5/Lv0PBWXQCggsMZA1AGkdzSDvBmYeHC2JED iU4An15g6IGrG/yU4mgWokKnVkXdnW0O =eLbx -END PGP SIGNATURE- - 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: How to avoid session fixation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, David Delbecq wrote: | I think this is worth submitting a security issue request on tracker, | to ask that, at least, the container links the requester IP to the | session. I'm pretty sure that nobody will want to do this -- at least not without the ability to turn the feature off. You'll break a lot of users if you require session id <-> ip address matching. | Changing session ID upon login in container would be a good thing | imho, it would ensure ID become unknown to attacker after login, | wouldn't destroy user session (keep session, only change it's | identifier) and would work whatever authentication mechanism is used. | I completely agree. Christopher, I think your valve might be more attractive if it was able to change the id of the session and leave it at that. I'm not familiar enough with the Tomcat API to know if this is possible and/or a good idea. | Draw back is that webapp that rely on session id for some session | tracking mechanism would break. True, although most webapps probably use whatever session id is currently in use. If you did a lot of AJAX where the session id available to the page becomes out-of-date after a login, you will have to make special considerations for that. I think you'll find that this is not much of a problem. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkewsO8ACgkQ9CaO5/Lv0PBWXQCggsMZA1AGkdzSDvBmYeHC2JED iU4An15g6IGrG/yU4mgWokKnVkXdnW0O =eLbx -END PGP SIGNATURE- - 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: How to avoid session fixation?
I think this is worth submitting a security issue request on tracker, to ask that, at least, the container links the requester IP to the session. Changing session ID upon login in container would be a good thing imho, it would ensure ID become unknown to attacker after login, wouldn't destroy user session (keep session, only change it's identifier) and would work whatever authentification mecanism is used. Draw back is that webapp that rely on session id for some session tracking mecanism would break. btw, you hack is limited to form based authentification, i successfully "shared" an authentificated session on tomcat 5.5.7 using http basic authentification. One of computer had access to secured ressouce whithout ever being prompted for user/pass En l'instant précis du 08/02/08 10:49, Christoph Lenggenhager s'exprimait en ces termes: David, Christopher Thank you for sharing your thoughts. It seems to me that there is no standard solution to this problem, but you agree with me that the problem exists. As I mentioned before, I came up with a solution that looks promising. Here's a rough description, I'd welcome your opinions/concerns: - a custom valve contains the whole implementation - requests to the servlet/URI "j_security_check" are intercepted - for intercepted requests the current session is destroyed and a new one is created: -- snip -- ... request.getSession().invalidate(); request.getSession(true); ... -- snap -- - to have a proper redirect to the originally requested page the original request has to be copied from the old session to the new one. I filter out any references to the old session id, although I'm not sure whether this is really necessary. Well, first of all, I'm in the comfortable situation that I'm not interested in any session attributes that existed before the actual login, so this make things easier. Furthermore, it's clearly a homemade hack, but it seems to do the job. Do you think it's worth to open a bug/feature request concerning this issue? For I actually think that this is clearly a task the container should take care of. Thanks. regards, christoph - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.devlog.be (a belgian developer's logs) - 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: How to avoid session fixation?
David, Christopher Thank you for sharing your thoughts. It seems to me that there is no standard solution to this problem, but you agree with me that the problem exists. As I mentioned before, I came up with a solution that looks promising. Here's a rough description, I'd welcome your opinions/concerns: - a custom valve contains the whole implementation - requests to the servlet/URI "j_security_check" are intercepted - for intercepted requests the current session is destroyed and a new one is created: -- snip -- ... request.getSession().invalidate(); request.getSession(true); ... -- snap -- - to have a proper redirect to the originally requested page the original request has to be copied from the old session to the new one. I filter out any references to the old session id, although I'm not sure whether this is really necessary. Well, first of all, I'm in the comfortable situation that I'm not interested in any session attributes that existed before the actual login, so this make things easier. Furthermore, it's clearly a homemade hack, but it seems to do the job. Do you think it's worth to open a bug/feature request concerning this issue? For I actually think that this is clearly a task the container should take care of. Thanks. regards, christoph - 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: How to avoid session fixation? [securityfilter-specific response]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, Christopher Schultz wrote: | This is interesting for the securityfilter project, which DOES allow | drive-by logins. Hmm. I'll have to think about this one. Thanks! I checked, and a login attempt on an existing authenticated session results in securityfilter destroying the existing session and creating a new one for the new login. Existing sessions with NO authentication information are preserved, which means that securityfilter is also vulnerable to Session Fixation (which is essentially informed-session-hijacking). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeqOz8ACgkQ9CaO5/Lv0PDDWwCfcBx1ICpXnE15Wjb+H/H8l/qm HN0An2Reti6iy5ryEqRaIY1gbb6Vc3Gt =hjZf -END PGP SIGNATURE- - 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: How to avoid session fixation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, david delbecq wrote: | Sorry Christopher, but i tried at work, it's very easy to force a user | to use a specific sessionid, and later use yourself that session id to | gain that user's credential, and for the whole session there is only one | login, the one from the user you attempt to hijack. Right, I knew that Tomcat was vulnerable to session hijacking. | As such, tomcat is | vulnerable to session fixation issues. Tomcat does not check where the | session originates from (IP of requester is not associated with | session). By passing a ;jssessionid= to a url and asking someone to | "check something on that url", you can, after that user logged in, use | yourself the same url to gain that user's credential. Perhaps I misread the Session Fixation idea. I thought it was: 1. Login as a low-privileged user 2. Return that browser to the login page without logging-out 3. Convince a higher-privileged user to login using the same session 4. Hijack the session in another browser I believe this scenario is not possible in Tomcat due to the restrictions I outlined in my previous message. On the other hand, skipping #1 and /not/ logging-in as a a lowly user first /will/ allow session hijacking. I believe the only way to prevent Session Fixation is to switch-up sessions at authentication time. I suppose a container-based implementation could change the id of the session and keep the physical session in-tact. Non-container strategies would have to move any relevant data from the untrusted session to the newly created session. That might have odd consequences for objects that implement SessionBindingListener and expect that removal from a session is the end of the session. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkeqOkAACgkQ9CaO5/Lv0PDDFACeJKbBCBe5Wu762rofwzJ5GyYJ 1q0AmN3QOhYEFasvmKFaVa+SiBo= =4j+K -END PGP SIGNATURE- - 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: How to avoid session fixation?
Sorry Christopher, but i tried at work, it's very easy to force a user to use a specific sessionid, and later use yourself that session id to gain that user's credential, and for the whole session there is only one login, the one from the user you attempt to hijack. As such, tomcat is vulnerable to session fixation issues. Tomcat does not check where the session originates from (IP of requester is not associated with session). By passing a ;jssessionid= to a url and asking someone to "check something on that url", you can, after that user logged in, use yourself the same url to gain that user's credential. Note: we use tomcat 5.5.7, maybe this has been fixed in later versions Christopher Schultz a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph, Christoph Lenggenhager wrote: | I'm currently trying to find a way to fight "Session Fixation" | (http://www.owasp.org/index.php/Session_Fixation) in tomcat when using | the built -in mechanisms to authenticate users of a servlet. I don't believe that Tomcat suffers from this problem. Without trying it, I would imagine that a user cannot authenticate twice using the built-in mechanism. When a remote user requests a protected resource, Tomcat checks to see if the user has authenticated already. If she has, Tomcat checks for authorization. If the user is not authorized, the request is rejected. If the user was not authenticated, the user is challenged for authentication and the process picks up after authentication. If a login request comes in without Tomcat expecting it, the request is rejected. Ergo, there's no way to login once and then expect someone to login afterward. If you are using your own authenticator, then this could be a problem. | In the | environment in question, an own realm implementation is in place and | we use the SingleSignOn feature as well. Have you demonstrated this problem in your own environment? If so, how did you do it? | Or is it in fact not a problem at all? See above. | A common solution to fix the problem is to renew the session (or at | least it's id) right before/after the user is authenticated (i.e. in | the same request). I came up with a custom valve that kind of does the | job, but I'm really not sure whether this is the way to go or if I'm | messing too much with tomcat internals. I would make sure it's a problem first, and then fix it. This is interesting for the securityfilter project, which DOES allow drive-by logins. Hmm. I'll have to think about this one. Thanks! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeqFawACgkQ9CaO5/Lv0PDMIQCfdE5LNfTtW1ZifQmW9us9QkuB qFEAnRkWyeRSII8qJ4noef5uzzQ6u6tl =YRiq -END PGP SIGNATURE- - 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: How to avoid session fixation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph, Christoph Lenggenhager wrote: | I'm currently trying to find a way to fight "Session Fixation" | (http://www.owasp.org/index.php/Session_Fixation) in tomcat when using | the built -in mechanisms to authenticate users of a servlet. I don't believe that Tomcat suffers from this problem. Without trying it, I would imagine that a user cannot authenticate twice using the built-in mechanism. When a remote user requests a protected resource, Tomcat checks to see if the user has authenticated already. If she has, Tomcat checks for authorization. If the user is not authorized, the request is rejected. If the user was not authenticated, the user is challenged for authentication and the process picks up after authentication. If a login request comes in without Tomcat expecting it, the request is rejected. Ergo, there's no way to login once and then expect someone to login afterward. If you are using your own authenticator, then this could be a problem. | In the | environment in question, an own realm implementation is in place and | we use the SingleSignOn feature as well. Have you demonstrated this problem in your own environment? If so, how did you do it? | Or is it in fact not a problem at all? See above. | A common solution to fix the problem is to renew the session (or at | least it's id) right before/after the user is authenticated (i.e. in | the same request). I came up with a custom valve that kind of does the | job, but I'm really not sure whether this is the way to go or if I'm | messing too much with tomcat internals. I would make sure it's a problem first, and then fix it. This is interesting for the securityfilter project, which DOES allow drive-by logins. Hmm. I'll have to think about this one. Thanks! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeqFawACgkQ9CaO5/Lv0PDMIQCfdE5LNfTtW1ZifQmW9us9QkuB qFEAnRkWyeRSII8qJ4noef5uzzQ6u6tl =YRiq -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
