14 Replies Latest reply on Jun 3, 2007 1:48 PM by avbentem

    sessionId cookie: man-in-the-middle attack

    lucluc

      I noticed that sessionId cookie sent to client before authentication remains the same even after login succedeed. This could lead to a man-in-the-middle attack because pre-login sessionId could be easily sniffed.

      So, it would be very nice if it should be possible to do a session switching on server side forcing a pre-login session invalidation and a new session creation (request.getSession(true)) as soon as client authenticates. Old session data should then be copied to new session.
      In this case a new sessionId cookie will be sent to client: client will use this ticket during next requests.

      This mechanism collides with the actual Seam implementations where Lifecycle.endSession is called after a session.invalidate
      I think that Seam should automatically execute this task during the authentication phase.

      regards

        • 1. Re: sessionId cookie: man-in-the-middle attack
          gavin.king

          Interesting, please create a JIRA issue and assign it to Shane, thanks.

          • 2. Re: sessionId cookie: man-in-the-middle attack
            lucluc

            DONE.

            I originally saw this mechanism implemented in jGuard: the best authentication/authorization library I've ever seen.

            • 3. Re: sessionId cookie: man-in-the-middle attack
              neill_robbins

              Hiyah,

              Apologies for maybe appearing thick...

              Why is the second session less likely to get sniffed than the first?

              Cheers
              N

              • 4. Re: sessionId cookie: man-in-the-middle attack
                christian.bauer

                Exactly. That's why the JIRA issue was rejected. This is obscurity, not security.

                • 5. Re: sessionId cookie: man-in-the-middle attack
                  modoc

                  I think the most likely scenario where this could be an issue and the proposed solution would help is if some of your site is http, but post-login, it changes to https to deal with more secure/personal information and features.

                  I wouldn't tie this session swapping to the login process, but rather make it useable wherever the app developer wants, probably when a protocol change is made.

                  Thoughts?

                  Devon

                  • 6. Re: sessionId cookie: man-in-the-middle attack


                    > your site is http, but post-login, it changes to https

                    ...but then anyone sniffing would also have read the username and password, right?

                    • 7. Re: sessionId cookie: man-in-the-middle attack
                      gavin.king

                      How about if we made it an option (probably even the default option) to automatically destroy the session every time the scheme changes?

                      • 8. Re: sessionId cookie: man-in-the-middle attack


                        > your site is http, but post-login, it changes to https

                        Ohh, I guess you mean pre-login. Like one could be browsing a site using HTTP. Then, when clicking a login link or payment link one would get to a HTTPS page at which the credentials are entered. So, the credentials are encrypted as well.

                        Yes, I assume Gavin's idea to rotate the cookie whenever the protocol changes might be good.

                        • 9. Re: sessionId cookie: man-in-the-middle attack
                          modoc

                          @avbentem: Yes, sorry, pre-login.

                          @Gavin: sounds like a good solution to me.

                          • 10. Re: sessionId cookie: man-in-the-middle attack
                            gavin.king

                            Done in CVS :-)

                            • 11. Re: sessionId cookie: man-in-the-middle attack
                              modoc

                              Awesome! That's what I love about open source. Thanks!

                              • 12. Re: sessionId cookie: man-in-the-middle attack

                                 

                                "fguerzoni" wrote:
                                forcing a pre-login session invalidation and a new session creation (request.getSession(true)) as soon as client authenticates. Old session data should then be copied to new session.
                                In this case a new sessionId cookie will be sent to client: client will use this ticket during next requests.

                                I think the changes for this JBSEAM-1361 cover Gavin's proposal in this forum topic, but note that existing session data might not be preserved. The session is invalidated using Seam#invalidateSession(), and I think at that point any old session data is lost.

                                But: I'm not sure; comments welcome!

                                Arjan.

                                • 13. Re: sessionId cookie: man-in-the-middle attack
                                  gavin.king

                                   

                                  Old session data should then be copied to new session.


                                  OK, I guess I can see how this is useful in some cases of upgrading from HTTP to HTTPS, but actually I was thinking more of the opposite case of HTTPS back down to HTTP. At this point the session data should be destroyed, since it can have sensitive information in it (esp. in a stateful Seam app).

                                  However, my current implementation didn't account for multi-window operation (!) so I will have to actually enhance it to "remember" the latest scheme because (correct me if I'm wrong) browsers don't actually maintain two session ids, one for HTTP and one for HTTPS, they just pop up an impenetrable and ignorable dialog to the user saying "you are about to change from a secure to an insecure connection". Right?

                                  • 14. Re: sessionId cookie: man-in-the-middle attack

                                    > browsers don't actually maintain two session ids,
                                    > one for HTTP and one for HTTPS

                                    Ohhh, good thinking...!

                                    You might know that a cookie can be set to be secure, and should then not be used for plain HTTP. I guess all browsers support that and won't send secure cookies over non-SSL connections.

                                    Of course we can also find specifications for the specific situation you describe, but I doubt one can rely on those being implemented alike by all browsers. Like what happens while switching, and while using HTTP and HTTPS simultaneously. Maybe some browser sends back two cookies for SSL connections: both the HTTP and HTTPS cookies -- but then how would one tell from the HTTP header which is which... And another browser or a future version might do it differently I suppose. So: that's not going to help.

                                    I assume the actual session handling is not done by Seam, right? (thus: one cannot use different cookie names for HTTP and HTTPS)