RE: HTTP State Management Mechanism (Rev1): EndSession attribute

On Tuesday, April 29, 1997 12:02 AM, Josh Cohen [SMTP:josh@netscape.com] 
wrote:
> Hi Mike,
>
> 	I understand the problme you are trying to solve, but I see
> a large number of difficulties with the method which you are trying to
> solve it.
>
> > The problem that occurs is that some users do not press the logout 
button.
> >
> >  When this occurs, the mainframe must hold the resources associated with
> >  the
> > context until the timeout occurs.  In some cases, this involves holding
> > database resources and memory resources that impact overall system
> > performance.  A malicious user might even mount a denial of service
> > attack
> > by  starting many sessions.
> >
> 1 On the D.O.S. attack, I dont really see how this helps.  In mounting
> any serious attack, the attacker would be smart to write a small
> client program to produce many sessions, assuming it could
> defeat a duplicate IP addr check ( multi session same client ),
> it could simply choose never to honor your endsession url..

I agree, a clever programmer will write a program.  This would only stop 
beginners.

> 2 What about people like me who leave their browsers running forever,
> I just lock my screen at night, etc..  The endession would never
> get executed.

The server will be required to have a timeout on the sessions.
I tried to explain that in the initial post.

However, always relying on the timeout will force servers to hold resources 
longer
than necessary.  One sure event that could be trapped is browser shutdown. 
 Any
sessions that are terminated prior to the server defined timeout will help.

> 3 Dont cookies often persist longer than the 'browser session' ?
> ie stored in the cookie file?  SHould the browser delete the cookie
> on shutdown ?

Some cookies can persist longer than the browser session, but the State 
Management spec
states that the DISCARD attribute, and Max-Age attributes will control this.

> 4. What is the method which the endsession URL should be submitted?
> POST, GET?  What is the browser to do with the response?

This could be specified in the EndSession attribute.  However, I suspect it 
should be a POST.

> 5. Security.
> Gee, this sounds like a nice way for a site to induce a client
> to access an abritrary URL at shutdown.   What if the URL is a
> file containing Java, ActiveX or the like ?

I agree this is a concern.  This concern is exactly why the browser needs to 
implement
user control over whether this attribute is processed.  For the inTRAnet 
case, the
server would be trusted, and this is not a concern.  I suggest that the 
browser be configurable
to specify a set of trusted servers that this attribute will be accepted 
from.

Michael Giroux

Received on Monday, 28 April 1997 19:11:38 UTC