[Zope] How SESSIONs work

Jim Penny jpenny@universal-fasteners.com
Thu, 21 Feb 2002 15:04:43 -0500


On Thu, Feb 21, 2002 at 11:00:34AM +0100, Milos Prudek wrote:
> >Generally, you don't.  The easiest way to prevent session theft is to
> >encode the stream, that is, use https.
> 
> Absolutely.
> 
> Perhaps I misunderstood. You said that sessionid key is not 
> cryptographically secure. Did you mean the Zope implementation in 
> particular, or Cookie-based sessioning in general?

Generally it is not much of a problem.  It just has to be unique,
and random enough in a large enough search space to not permit
accidental collision.  This is true in general.  You just don't
care (much).  More below.

> 
> I lack experience with cookie theft. My understanding is that a cookie 
> theft is achieved either because server side was tricked by a third 
> party to divulge the cookie *or* en-route ISP is simply listening and 
> capturing HTTP traffic. In either case the third party can then set the 
> cookie in his browser and finish the transaction that the original 
> cookie owner started, and otherwise impersonate the cookie owner if this 
> cookie persists between browser sessions. Is this correct?

Yes, cookie theft requires either a bug in a browser, an inadequate
security policy or a sniffer.   https can protect you from sniffers,
it cannot protect your from browser bugs.  Use https, it gets rid of
one major worry (actually two, since basic authentication sends userids
and password in the clear if you are using only http).

> 
> 
> >This is not strictly true.  You can invalidate the sessionid on the
> >both server and client when the transaction is done and issue a new one.
> 
> So if I gather information from user on five screens and I use cookie to 
> maintain information entered in previous screens, that's what sessioning 
> is about, isn't it? Do you suggest that I should invalidate the cookie 
> after each of these five screens and issue a new one? That would trash 
> the data maintained in the original session (I'm using CST, 
> CoreSessionTracking).

No, you want to keep the same session active during each of the 
five screens.  Otherwise you will have to do a lot of work, mainly
updating whatever server side store you have for the session data 
to point to the same sessionid.  If you are not "rolling your own"
sessions, this may not even be possible.

Think of it this way.  A session key has roughly as much value as
it has lifetime.  If the same sessionid is kept open for you for years,
then there is high value in knowing that sessionid.  It allows the
intruder to take an action under the identity of the authorized user.
(Worst case, the sessionid, stored in a cookie, is used to do 
authentication and authorization -- such a cookie has unlimited value.
The programmer who created such a cookie does not!)

If a sessionid is alive only for minutes, then it has relatively low
value.  The intruder can impersonate you, but only for a short window
of time.  After that he has to either follow your session trail or
he has to trick you into disclosing your cookies to him again.

If you are using https, then he probably cannot follow the session
trail, so that leaves him with two approaches.  1)  Use the normal
(usually javascript based) bugs in browsers to get them to divulge
cookies inappropriately.  Problem with this is that you have to visit
an attacker's website and your cookie has to be valid when this site
is visited.  Not a vanishingly small concern, but certainly quite small,
assuming your cookies have relatively short life.

Or, he has to get another agent, a bit of malware, perhaps a virus,
a trojaned daemon, an ActiveX, or somthing of this ilk that can
periodically scan your hard drive for cookie changes and transmit
them out to the attacker.  If your attacker has this level of
sophistication, you are probably dead meat.

But, as far as I know, such attacks are not common in the wild.
First, would depend on the attacker knowing a lot about the victim,
i.e. operating system, browser, maybe mail reader.  Secondly, they 
would have to be pretty narrow.  If the attack were broadly based,
two things would happen.  First, the attacker would probably attract
the notice of the anti-virus industry; and second, the traffic that
is of time critical value, namely the cookies, would lead the world
back to the attacker.  That is, he cannot continue to use the cookies
without (eventually) being caught.

Now if your attacker is an agent of a government, or perhaps a 
really knowledgable insider, you really have no defense.  Govenments can
do more, and cookie theft would probably be kind of pointless.  The right 
sort of insider, a real BOFH, could conceivably cause you great 
embarassment, and even get you fired.  But, again, such an individual 
probably has better means at his disposal than cookie theft.

In reality, this is a relatively small problem if your cookies are
transient.  But, there is a compromise here.  Your cookies must
live long enough for the user to consistently complete this transaction.

There is one more reason to not be especially fearful of cookie theft.
Remember, the way sessionids use cookies, they are really just a key
into a database on the server that store the current state of one or
more of your interactions with the server.  In general, the attacker
cannot see the state on the server, only the cookie of the user.
In practice, this means that the attacker must not only get the cookie, 
but must also know what the user was doing with that particular cookie
(sessionid).  If the attacker cannot follow the entire transaction,
he can get the cookie (sessionid), but still will have no idea of what
it is good for.  So, this comes back to SSL, if the attacker can get
only the cookie, without knowing what the state stored on the server is,
it has no value.

If you are working in an area with enormous financial stakes, or where
secrecy is a must -- well, I am not sure I would use cookies.  I am not
sure that I would trust standard browsers, they are just too big and too
complex, and source code may not even be available.  You also don't want
to use passwords, you want biometrics and some kind of one time pad for
authentication and authorization, and you will still lose sleep at
night.

But for most realistic scenarios, sessionid theft is not critical and
probably not even exploitable, provided the attacker cannot sniff all
traffic between server and client.

Jim Penny

> 
> -- 
> Milos Prudek
> 
>