[hunchentoot-devel] Fwd: hunchentoot session hijacking

[Anton Vodonosov]

on Monday, October 27, 2008, 12:16:42 PM Hans wrote:

> Hi Anton,

> thank you for the patches.  I have committed the CL+SSL patch both
> upstream and in my repository.

> For the session secret update:

> - The name *SESSION-SECRETIZER* really does not cut it.  I would
> suggest that *SESSION-SECRET-SALT* is more suitable.
Yes, that's better :)

> - The docstring and documentation file should be clear about the
> expected datatype of the variable (string?)
Yes, I forgot. It must be string.

> - I don't like the warning if the only way to set up the salt is
> setting the special variable.
> - Maybe it would be better to supply the concerned user with a way to
> override the ENCODE-SESSION-STRING function instead of having them
> mess with the internals of the current session secret encoding
> function.

Overriding ENCODE-SESSION-STRING is more complex responsibility
for users - they must deal with four parameters: session-id,
user-agent, remote-addres and session-start-time; and with
*USE-USER-AGENT-FOR-SESSIONS*, *USE-REMOTE-ADDR-FOR-SESSIONS*; and
they must understand that the result must unique and unguessable.

I also thought about providing a possibility to overrride
RESET-SESSION-SECRET, as  you suggested in the previous email (btw,
how "overrride"? just redefine or clos-specialize on artificially
introduced parameter). But in this case we need to export both
RESET-SESSION-SECRET and *SESSION-SECRET* and explain people that
generated secret must every time be not only unguessable but also
unique, which is an extra responsibility for them.

Therefore, although I do not like too much introduction of the new
special variable, it is the simplest way I see. The only thing
we need is the salt, and users just provide it. Hunchentoot does
all the remaining job.

> I would like to know what Edi thinks about this before committing this
> or any other patch to the repository.

Ok.

Best regards,
- Anton