[hunchentoot-devel] Sessions not secure?

Sohail Somani sohail at taggedtype.net
Wed Dec 26 21:09:37 UTC 2007


On Wed, 26 Dec 2007 18:18:24 +0100, Edi Weitz wrote:

> On Sun, 23 Dec 2007 23:31:03 +0100, Edi Weitz <edi at agharta.de> wrote:
> 
>> On Sun, 23 Dec 2007 22:22:22 +0000 (UTC), Sohail Somani
>> <sohail at 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?

-- 
Sohail Somani
http://uint32t.blogspot.com




More information about the Tbnl-devel mailing list