[DEAD PROPOSAL] When Session Max reached, throw out oldest session

[bo...@jadn.com]

OK.  Based on everyones feedback, 5 or more against, 1 for, I pronounce this
proposal officially DEAD.  

Cheers,
-bob


> Allowing people to configure something this dangerous is hurting them, not
> helping them.
> 
> > I like the LRU system because; I know I have 50Mb of session RAM.  I
> > know each session can use up to 10k of memory.  So my server can
> > support 5000 sessions.  I dont care how long the sessions are
> > inactive..  so If it lives a month or two (like amazon's) that is just
> > dandy with me.  The algorthim only throws away the oldest when it has
> > to.
> 
> Here's pseudocode for a sample attack program that totally screws up your
> application if you choose the "throw out the oldest" scenario:
> 
>   for (i = 0; i < 5000; i++) {
>     send a request that causes a new session to be created
>   }
> 
> No need to remember the session ids you created -- in fact, you would not
> want to, because your intent is to cause new ones to be created.
> 
> I've just kicked out all 5000 of your existing users.  And if I leave this
> thing running, nobody will ever to be able to log in for more than one
> request at a time, because the request rate from the attacker will cause
> your real user sessions to end up being "oldest" very rapidly.
> 
> Swapping an active session out to disk (without invalidating it) is a
> different feature, and one that is already supported by Tomcat.  The
> persistent session manager lets you separately configure the number of
> in-memory sessions versus the total number (including those that are
> swapped out).
> 
> But you still do NOT want the "invalidate the oldest algorithm", because
> the same attack would be possible -- it would just need to iterate to
> whatever your "total number" configured limit is set for.
> 
> 
> >
> > Cheers
> > -bob
> >
> > P.S. perhaps the LRU strategy should be employed when the Inactive
> > time is infinity.
> >
> 
> Craig
> 
> 
> > > -----Original Message-----
> > > From: GOMEZ Henri [mailto:hgomez@slib.fr]
> > > Sent: 19 June 2002 10:26
> > > To: Tomcat Developers List
> > > Subject: RE: [PATCH] When Session Max reached, throw out oldest session
> > >
> > >
> > > >Agreed... If we start invalidating sessions when too much memory is
> > > >"wasted", I'm going to choose a different servlet engine for
> > > >my 10m req/day
> > > >site... :) If I define that a session has a timeout, I want
> > > >that timeout to
> > > >be _real_ and if I run into memory problems, well, that's my
> > > >problem, not
> > > >yours (servlet engine developers)...
> > > >
> > >
> > > I agree.
> > >
> > > If there is no more slots open for incoming connections (clients),
> > > then the servlet engine should return an error, which could be
> > > handled by a redirector like mod_jk or mod_webapp to forward the
> > > request to another Tomcat.
> > >
> > > I'm really against dropping existing sessions.....
> > >
> > > --
> > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >
> > > **** DISCLAIMER ****
> > > "This e-mail and any attachments thereto may contain information
> > > which is confidential and/or protected by intellectual property
> > > rights and are intended for the sole use of the recipient(s) named above.
> > > Any use of the information contained herein (including, but not limited to,
> > > total or partial reproduction, communication or distribution in any form)
> > > by persons other than the designated recipient(s) is prohibited.
> > > If you have received this e-mail in error, please notify the sender either
> > > by telephone or by e-mail and delete the material from any computer.
> > > Thank you for your cooperation."
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >
> >
> > Cheers,
> > -bob
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 

Cheers,
-bob

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>