Hello all,

I'm new to this list (my first post).  I'm currently in a project for SANS certification in which I'm auditing Zope security.  I just noticed that every time I log in I get a cookie from the server that has the following info:

Name:  tree-s
Data: "eJzTiFZ3hANPW/VYHU0ALlYElA"

The data is ALWAYS the same.  I got the same cookie from a Redhat 7.1 box runnning Zope 2.3.2 as I did from an NT box running Zope 2.4.0.  What is this cookie used for in the management process?  I'm not at all familiar with Zope's innards (but hopefully I'll get familiar with the security innards at least).  Also, trudging through all the source code to find the answer to this is not really a reality for me given the fact that my Python experience is not deep enough. 

On a separate but related note, could anyone forward me links describing the security innards?  I am familiar enough with Zope to know that only certain modules can be imported, etc.  However, I've had a really hard time finding anything more detailed than the security howtos that describe assigning permissions & such through the management interface.  All the security precautions that have been taken into account when developing the core of Zope are of interest to me.  Basically, the project is to hack zope before the hackers do.  Hopefully, I won't find anything (or at least just little stuff like I mention in the next paragraph).  What I hope will result of this is a checklist that people can go through to harden their Zope boxes.

Also, if this is the wrong list to be asking about the security features of the innards, please direct me to the appropriate place.  I hope to come up with a substantial review of Zope from a security standpoint.  I've already found a couple of things that could be done to help (small things), like editing the header lines in HTTPResponse.py to not give up the server version info in the HTTP headers.  Changing it to something like "Atari 2600 SuperServer" would at least keep the hackers from knowing you're running Zope 2.x.y and finding related vulnerabilities...=).

Thanks,
Dave Thibault