[Zope] Core Session Tracking questions

[Chris McDonough]

(There is also the more common DOS case where a malicious script hitting a
session-write method repeatedly will cause RAM consumption to increase
without bound too.  This may be ameliorated to some degree if you use an
external session data container in a disk-based storage, because it doesn't
need to have all of its objects in RAM at once).

----- Original Message -----
From: "Chris McDonough" <chrism@digicool.com>
To: "Jérôme Loisel" <jerome@levinux.org>; <zope@zope.org>
Sent: Saturday, March 03, 2001 4:51 PM
Subject: Re: [Zope] Core Session Tracking questions


> Hi Jerome,
>
> > First question: Say my cookies are set to last 14 days, but my session
> data
> > manager only stores session data for 60 minutes... What happens? Say a
> > visitor comes, sets some preferences, leaves and comes back two days
> later. A
> > new session oject is created. Are the old cookies "imported" in the new
> > object or is the data lost?
>
> The data is lost.  The data container timeout determines how long the data
> sticks around, not the cookie timeout (the cookie contains what you can
> think of as a "browser id" rather than a "session id", although the docs
> claim its a sessionid... this is why the docs go into some explanation of
> this phenomena).  In many cases, it's desirable to use a session id as...
> well.. a session id, instead of trying to use it to associate data with a
> user for time immemorial.  One common pattern is to use a session data
> object to store data about the user until they log in.  Then when they log
> in, you copy the data from the session data object to an object associated
> with the user, and then clear the session data, considering the
> user-associated data canonical.
>
> > Second question (not really as important for me): Is a Core Session
> > Trackink-enabled site not more vulnerable to DOS attacks? Are there
plans
> to
> > eventually add sometghing to protect against OOM situations due to DOS
> > attacks, like limiting the maximum amount of RAM used by core session
> > tracking?
>
> Are you allowing people to script DTML or other through-the-web code on
your
> site?  If so, then, yes, probably.  If not, then yes, perhaps.  ;-)
>
> There is one failure case in core session tracking that hasn't yet been
> addressed (even if folks can't script DTML on your site):  because session
> data objects are stored in the ZODB, they are prone to conflicterrors on
> write.  The data structures used by the session data containers are
designed
> to minimize conflict, but in the case that lots of folks come in with the
> *same* session id at the same time, and they visit a method which writes
to
> that session data object, your site might experience some denial of
service
> due to conflicts hogging the ZODB connections.  A determined script kiddie
> could make this happen pretty easily with a script that fired off a bunch
of
> reader threads that pretended to be clients with the same session cookie,
> hitting a method which did a session write.  Or it could happen if a
> session-encoded URL was posted to Slashdot.  You can minimize the
> possibility of this happening (especially if you run a public site) by not
> using URL-encoded session ids.
>
> I'd like to minimize the possibility of this failure by writing some code
in
> the session id manager that rejects multiple requests that claim to have
the
> same session id in some very short timespan.  But it's a tricky problem,
> because there could be a legitimate situation in which this could occur.
In
> any case, I haven't yet addressed it.
>
> > PS: BTW, thanks again for Core Session Tracking. So far, it looks really
> > cool: powerful and dead simple to use. The documentation in help/ seems
> > needlessly compicated, though.
>
> Hee hee... damned if you do, damned if you don't.  Write docs, that is.
;-)
>
>
> _______________________________________________
> 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 )
>