[Zope] How SESSIONs work

Jim Penny jpenny@universal-fasteners.com
Wed, 20 Feb 2002 10:44:16 -0500


On Tue, Feb 19, 2002 at 06:52:07PM +0100, Milos Prudek wrote:
> 
> >The only information in the cookie is the browser ID -- just a unique 
> >key to retrieve the session data saved on the server.  The key is NOT 
> >cryptographically secure -- capturing the key would enable you to steal 
> >a session if the application didn't check for that.  This is intended, 
> 
> This raises an interesting question: How do you check in the application 
> if section was stolen?

Generally, you don't.  The easiest way to prevent session theft is to
encode the stream, that is, use https.

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.
In that way, your session holder will certainly detect id theft.  
He completes his transaction, the sesionid is invalid, and error 
is raised.  Unfortunately, the user is as likely to blow it off as 
a bug, as think that it is actually a security problem....

Also, note that a cookie is not the only way to propagate a sessionid;
it is just a convenient one.  It is equally possible to store the
sessionid as hidden data (but it is much more work to make sure that the
sessionid appears in every form where it is needed.)

Hidden variables and such make more sense when you start thinking less
about sessionid (valid for a long time and many interactions), and more
about a transactionid  (valid for only a few interactions, typically
only long enough to gather all the information needed to complete a 
single transaction).

Jim Penny

> 
> -- 
> Milos Prudek
> 
> 
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists - 
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope-dev )
>