Hi,
In the documentation for Hunchentoot it says that start-session either uses a cookie or url rewriting to maintain the session state. Then it goes on to say:
Hunchentoot makes some reasonable effort to prevent eavesdroppers from hijacking sessions (see below), but this should not be considered really secure. Don't store sensitive data in sessions and rely solely on the session mechanism as a safeguard against malicious users who want to get at this data!
What is it referring to when it says "see below?" If we assume malicious users can get at the data, is this different from session hijacking?
I am assuming (maybe incorrectly) that the following sequence is as secure as the user name and password.
* User connects via https (no session exists) * Since no session exists, user is redirected to some login page * User enters user name and password and submits form * This information is authenticated and a session is created * (setf hunchentoot:*session* (start-session)) * On subsequent requests, since the user has a session, we can assume they are authenticated.: * (unless hunchentoot:*session* (redirect-to-login-page))
I guess it all hinges on start-session and how it generates the session id's.
Thanks.
[fixing formatting, I hope]
Hi,
In the documentation for Hunchentoot it says that start-session either uses a cookie or url rewriting to maintain the session state. Then it goes on to say:
Hunchentoot makes some reasonable effort to prevent eavesdroppers from hijacking sessions (see below), but this should not be considered really secure. Don't store sensitive data in sessions and rely solely on the session mechanism as a safeguard against malicious users who want to get at this data!
What is it referring to when it says "see below?" If we assume malicious users can get at the data, is this different from session hijacking?
I am assuming (maybe incorrectly) that the following sequence is as secure as the user name and password.
- User connects via https (no session exists) - Since no session exists, user is redirected to some login page - User enters user name and password and submits form - This information is authenticated and a session is created: - (setf hunchentoot:*session* (start-session)) - On subsequent requests, since the user has a session, we can assume they are authenticated.: - (unless hunchentoot:*session* (redirect-to-login-page))
I guess it all hinges on start-session and how it generates the session id's.
Thanks.
On Sun, 23 Dec 2007 21:36:43 +0000 (UTC), Sohail Somani sohail@taggedtype.net wrote:
In the documentation for Hunchentoot it says that start-session either uses a cookie or url rewriting to maintain the session state. Then it goes on to say:
Hunchentoot makes some reasonable effort to prevent eavesdroppers from hijacking sessions (see below), but this should not be considered really secure. Don't store sensitive data in sessions and rely solely on the session mechanism as a safeguard against malicious users who want to get at this data!
What is it referring to when it says "see below?"
The explanation of the details of the session mechanism, specifically *USE-REMOTE-ADDR-FOR-SESSIONS* and *USE-USER-AGENT-FOR-SESSIONS*.
If we assume malicious users can get at the data, is this different from session hijacking?
No.
I am assuming (maybe incorrectly) that the following sequence is as secure as the user name and password.
- User connects via https (no session exists)
- Since no session exists, user is redirected to some login page
- User enters user name and password and submits form
- This information is authenticated and a session is created
- (setf hunchentoot:*session* (start-session))
- On subsequent requests, since the user has a session, we can assume they are authenticated.:
- (unless hunchentoot:*session* (redirect-to-login-page))
Yes, that's basically how it is usually done.
I guess it all hinges on start-session and how it generates the session id's.
To hijack a session someone has to get at the session ID. That's not Hunchentoot's problem, but if you (see above) already start with https, that's certainly a good thing. The question is what you can do with a foreign session ID once you have it. How long does it last? Will it work with different browsers and/or from different IPs? And so on.
Hunchentoot tries to provide a couple of options, but eventually you will have to make a decision.
On Sun, 23 Dec 2007 23:04:20 +0100, Edi Weitz wrote:
[snip]
The explanation of the details of the session mechanism, specifically *USE-REMOTE-ADDR-FOR-SESSIONS* and *USE-USER-AGENT-FOR-SESSIONS*.
[snip]
To hijack a session someone has to get at the session ID. That's not Hunchentoot's problem, but if you (see above) already start with https, that's certainly a good thing. The question is what you can do with a foreign session ID once you have it. How long does it last? Will it work with different browsers and/or from different IPs? And so on.
Hunchentoot tries to provide a couple of options, but eventually you will have to make a decision.
Ok, thank you for your clarifications. I went through the source and noticed that the session id's are generated sequentially. So one other way that sessions can be hijacked is by guessing the session ID. Of course, this is if you do not use the IP address and user agent options that you mentioned above. Otherwise, even if you use SSL, your session can be hijacked.
Hypothetically speaking, if I wanted to prevent hijacking by guessing, I could just redefine hunchentoot:get-next-session-id.
Does this sound correct?
Btw, great set of libraries. I don't know how you do it. My theory is that you are really three people.
On Sun, 23 Dec 2007 22:22:22 +0000 (UTC), Sohail Somani sohail@taggedtype.net wrote:
Hypothetically speaking, if I wanted to prevent hijacking by guessing, I could just redefine hunchentoot:get-next-session-id.
Does this sound correct?
Yes, I think so.
Btw, great set of libraries. I don't know how you do it. My theory is that you are really three people.
Four... :)
On Sun, 23 Dec 2007 23:31:03 +0100, Edi Weitz edi@agharta.de wrote:
On Sun, 23 Dec 2007 22:22:22 +0000 (UTC), Sohail Somani sohail@taggedtype.net wrote:
Hypothetically speaking, if I wanted to prevent hijacking by guessing, I could just redefine hunchentoot:get-next-session-id.
Does this sound correct?
Yes, I think so.
Er, no, actually. I've seen this mentioned in your blog
http://uint32t.blogspot.com/2007/12/abusing-hunchentoots-dispatch-mechanism....
and thought about it again. So, tell me, if you happen to know for sure that my session ID is 42 and if you also know my user agent string and my IP address, how would you construct a cookie to hijack my session?
Edi.
On Wed, 26 Dec 2007 18:18:24 +0100, Edi Weitz wrote:
On Sun, 23 Dec 2007 23:31:03 +0100, Edi Weitz edi@agharta.de wrote:
On Sun, 23 Dec 2007 22:22:22 +0000 (UTC), Sohail Somani sohail@taggedtype.net wrote:
Hypothetically speaking, if I wanted to prevent hijacking by guessing, I could just redefine hunchentoot:get-next-session-id.
Does this sound correct?
Yes, I think so.
Er, no, actually. I've seen this mentioned in your blog
http://uint32t.blogspot.com/2007/12/abusing-hunchentoots-dispatch-
mechanism.html
and thought about it again. So, tell me, if you happen to know for sure that my session ID is 42 and if you also know my user agent string and my IP address, how would you construct a cookie to hijack my session?
I lied. At the time of my post, I hadn't looked at enough of the code to make that judgement. The thing I was worried about is that (I thought) all the information that went into the md5sum'ed ID was deterministic. I thought it looked like:
* (concatenate 'string id user-agent ip-address)
All that is needed to make this work is to spoof the ip-address and user- agent, which is not trivial, but not hard either.
In reality, it looks like this:
* (concatenate 'string *session-secret* id user-agent ip-address time-of-session-start)
Since the *session-secret* is generated when the server starts and so is presumably random, it is somewhat secure (but I don't know enough about the Lisp random number generators to say.) Hopefully it isn't as pseudo- random as the C rand function which would more accurately be called rand_for_when_you_dont_need_rand.
Thanks for your time and thanks for making me clarify. I will update my post to that effect.
By the way, since you read the post, do you think it is use or abuse of the dispatch table?
On Wed, 26 Dec 2007 21:09:37 +0000 (UTC), Sohail Somani sohail@taggedtype.net wrote:
In reality, it looks like this:
- (concatenate 'string *session-secret* id user-agent ip-address time-of-session-start)
And don't forget MD5. Even if the random number generator were weak, you'd have a hard time to figure out where in the random sequence you are, right?
but I don't know enough about the Lisp random number generators to say.
This is obviously implementation-dependent. Some Lisp implementations also offer more choices for random number generators, for example:
http://www.lispworks.com/documentation/lw50/LWRM/html/lwref-326.htm
By the way, since you read the post, do you think it is use or abuse of the dispatch table?
I think it's a valid use. I've been doing things like that as well.
Edi.
On Wed, 26 Dec 2007 22:21:44 +0100, Edi Weitz wrote:
On Wed, 26 Dec 2007 21:09:37 +0000 (UTC), Sohail Somani sohail@taggedtype.net wrote:
In reality, it looks like this:
- (concatenate 'string *session-secret* id user-agent ip-address time-of-session-start)
And don't forget MD5. Even if the random number generator were weak, you'd have a hard time to figure out where in the random sequence you are, right?
Practically, yes. I think it still depends on the RNG and how much knowledge I have of your server setup.
To me, the documentation makes it seem like there is no randomness involved. I think it should mention that there is some randomness but the quality of the security is dependent on the quality of the RNG. In any case, Hunchentoot has done as close to an optimal job as is economical. In my highly unqualified opinion of course (IMHUQO?) :-)
but I don't know enough about the Lisp random number generators to say.
This is obviously implementation-dependent. Some Lisp implementations also offer more choices for random number generators, for example:
http://www.lispworks.com/documentation/lw50/LWRM/html/lwref-326.htm
Thanks! I've been meaning to try LW but SBCL is very nice to me so far :-)
-
Edi Weitz -
Sohail Somani