-
1. Re: sessionId cookie: man-in-the-middle attack
gavin.king May 28, 2007 2:13 PM (in response to lucluc)Interesting, please create a JIRA issue and assign it to Shane, thanks.
-
2. Re: sessionId cookie: man-in-the-middle attack
lucluc May 28, 2007 6:16 PM (in response to 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 May 31, 2007 5:33 AM (in response to lucluc)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 May 31, 2007 5:59 AM (in response to lucluc)Exactly. That's why the JIRA issue was rejected. This is obscurity, not security.
-
5. Re: sessionId cookie: man-in-the-middle attack
modoc Jun 2, 2007 5:27 PM (in response to lucluc)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
avbentem Jun 2, 2007 6:09 PM (in response to lucluc)
> 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 Jun 2, 2007 6:09 PM (in response to lucluc)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
avbentem Jun 2, 2007 7:12 PM (in response to lucluc)
> 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 Jun 2, 2007 7:43 PM (in response to lucluc)@avbentem: Yes, sorry, pre-login.
@Gavin: sounds like a good solution to me. -
10. Re: sessionId cookie: man-in-the-middle attack
gavin.king Jun 2, 2007 9:16 PM (in response to lucluc)Done in CVS :-)
-
11. Re: sessionId cookie: man-in-the-middle attack
modoc Jun 2, 2007 11:51 PM (in response to lucluc)Awesome! That's what I love about open source. Thanks!
-
12. Re: sessionId cookie: man-in-the-middle attack
avbentem Jun 3, 2007 9:24 AM (in response to lucluc)"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 Jun 3, 2007 1:25 PM (in response to lucluc)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
avbentem Jun 3, 2007 1:48 PM (in response to lucluc)> 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)