Ah.. here's another set of useful pages: http://dev.zope.org/Wikis/DevSite/Projects/CoreSessionTracking/UseCases and http://dev.zope.org/Wikis/DevSite/Projects/CoreSessionTracking/FrontPage . The answer, though, is that an indentifier for the session can be kept in the cookie or in a form value. - C ----- Original Message ----- From: "Bill Bell" <bill-bell@bill-bell.hamilton.on.ca> To: <zope@zope.org> Sent: Tuesday, February 19, 2002 7:32 AM Subject: Re: [Zope] How SESSIONs work On 2/18/2002 at 7:58 PM Chris McDonough wrote:

See the section of the Zope Book entitled "Using Sessions" within http://www.zope.org/Members/michel/ZB/BasicObject.dtml .

On 2/19/2002 at 3:01 PM Graham Chiu wrote:

There's a working documented example - the shopping basket - in the 2.5 download.

First of all, thank you for your responses to my question. Unfortunately I did not make my meaning clear. I would like an elementary understanding of how the internals of SESSIONs work. I assume they make use of cookies. If this is correct then, what information is sent back and forth using cookies? Again, thanks. ------------ "It is the time that you have wasted for your rose that makes your rose so important."--St-Exupery _______________________________________________ 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 )

Bill Bell wrote:

First of all, thank you for your responses to my question. Unfortunately I did not make my meaning clear.

I would like an elementary understanding of how the internals of SESSIONs work. I assume they make use of cookies. If this is correct then, what information is sent back and forth using cookies?

Yes, it uses cookies by default. It doesnt have to -- it can be enabled to use FORM variables, but that's tougher to do by default (the one component can't just behave passively.) There's an ID manager that assigns a cookie to a browser, a data manager that uses that ID to connect to a temporary session data store, and the data store itself. In conjunction, all three form a "session." 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, as the various proxy servers out there make uniquely identifying a browser in a secure fashion tricky. The only really good way to do that IMHO is SSL + cookies. -- Matt Kromer Zope Corporation http://www.zope.com/

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 )

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

I would like an elementary understanding of how the internals of SESSIONs work. I assume they make use of cookies. If this is correct then, what information is sent back and forth using cookies?

Well, you don't need to read anything. You can actually SEE the data exchange. If you are on Linux, download and install "ethereal". Run it to capture network traffic on http port. Study and enjoy. If you are on Windows, there's "Sniffer" (expensive commercial software) and I think there are some some shareware programs that can capture network traffic, but I don't know their names. -- Milos Prudek

I know one ;-)

http://www.ethereal.com/distribution/win32/

Errrr.... :-) -- Milos Prudek