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.