[Zope] forms: copying objects from request to request

[Joachim Werner]

Hi!

> 1) heavier machinery:
> You have to have a per-user repository for sessions.  A user can have
> an arbitrary number of sessions open at once (multiple browser windows).
> That means the session data can be very large.  And that tends to
> require external databases.  External databases and zope play very
> nicely together indeed, but it is an additional requirement.

We are talking about a couple of strings, not about storing MP3 files or
videos in the session ;-)

Zope's built-in session management does not need a database, though it might
have limitations for scenarios with lots of large sessions as it will
consume quite a lot of memory then.

> 2) policy problems:
> Each use can have an arbitrary number of sessions open.  HTTP does not
> signal when a session should be closed, sessions are thus held in a
> frozen, and often useless state if a user abandons a session without
> logging out.  This gives you one of two choices -- to time out a
> session after some amount of time, or to delete all sessions on login.
> [Logout is more natural, but you have no guarantee that logout will ever
> occur (the user may simply leave, or the browser crash, etc.)].
> Arbitrary timeouts are guaranteed to hurt someone, some time.  Login is
> more interesting, but makes session recovery after a crash more
> problematic.

Are these problems that are really serious? A decent timeout is fine with
me.

> 3) Session IDs:
> You have to grant a session ID.  How can it be stored?  In hidden data!
> (Or in the functional equivalent of a cookie.)
> And unless you are encrypting all traffic, these can be
> sniffed while on the network.  This gives a patient attacker plenty of
> opportunity to assume a session by simply responding to the request more
> quickly than the actual user.  This is something the user is likely to
> "see", but, I suspect something the user is not likely to report.
> That is, in some sense, sessions reduce to hidden variables.

Not quite. You can do a "man-in-the-middle" attack, yes. But you can do that
with every HTTP traffic that doesn't use SSL. And even then, you could
sometimes trick the client into encrypting against the key of the
"man-in-the-middle", who could then forward the data with his own key used
for encryption (though that only works if the user is not careful to read
the certificate info).

With sessions, the attacker only sees that there is a session. All the data
that isn't strictly needed for display at the browser end will stay on the
server.

> Look, HTTP is stateless, by design.  Sessions are stateful, by design.
> A stateless and a stateful system are bound to react in odd ways when
> used together, at least sometimes.

Indeed sessions are not perfect. Using multiple browser windows will break
some logic of session-based software. But that's the same with non-web
software: If I was able to open a new (cloned) window in the middle of a
conditional dialog in a Windows program, the program would also get rather
confused.

> Mind you, I am not blindly opposed to sessions; they sometimes make
> a great deal of sense, and I use them myself.   If you have a LOT of
> data to transfer and several layers of forms, they can make life much
> easier, as the data does not have to be remarshalled into each form.

That's the point ...

> Also, note that it is not hard to protect hidden variables, people just
> seldom do.  For example, you could take a secret, concatenate the hidden
> values and calculate a SHA signature of this string.  The server sends
> the hidden variabls, as usual, and also sends this SHA as an additional
> hidden variable.  Now when the server gets the form back, it performs
> the calculation again.  If the returned SHA does not match the newly
> calculated SHA, then the hidden variables have been tampered with and
> should be rejected.

I didn't know that one. Sounds reasonable to me.

> Recap:  use sessions when you have a lot of data to transfer across
> forms.  Use hidden variables when you have small amounts to move.
> Sessions are often more secure in practice, not because they are
> inherently a better idea, but because session authors have often
> thought the problems through.  In either case, if security is a
> concern, the sessionID and/or any hidden variables should be protected
> using a digital signature.  If you use sessions, be sure that you
> understand and document the session expiration policy.

Fully agreed at the end. I'd also not use sessions if I just had to forward
one or two attributes to the next screen ...

Joachim