[3894] in WWW Security List Archive
Re: Maintaining state with CGI
daemon@ATHENA.MIT.EDU (Chad Schieken)
Mon Dec 23 18:57:04 1996
To: Ben Camp <benc@geocel.com>
cc: "'Chad Schieken'" <cschieke@advsys.com>, John W Pierce <jwp@r2systems.com>,
"www-security@ns2.rutgers.edu" <www-security@ns2.rutgers.edu>,
cschieke@advsys.com
In-reply-to: Your message of "Mon, 23 Dec 1996 16:13:40 CST."
<01BBF0EC.436F0D00@silicon.geocel.com>
Date: Mon, 23 Dec 1996 17:18:59 -0500
From: Chad Schieken <cschieke@advsys.com>
Errors-To: owner-www-security@ns2.rutgers.edu
What happens when a user's IP address changes inside the same "session"?
state is not part of HTTP. If I/you/we/anyone had a really good solution =
they'd be really rich....
later...
chad
> Agreed, you cannot use IP address for authentication, however it is not=
wrong to use IP address to determine what a 'session' is. This of cours=
e would be coupled with a 'Time' element and a if available a REMOTE_USER=
variable. Other things could be used, such as Browser type/version or r=
eally anything that might differentiate users of the system.
> =
> Ben Camp
> =
> =
> ----------
> From: Chad Schieken
> Sent: Monday, December 23, 1996 3:40 PM
> To: Benjamin Camp
> Cc: John W Pierce; www-security@ns2.rutgers.edu; cschieke@advsys.com
> Subject: Re: Maintaining state with CGI =
> =
> Ben,
> =
> Your close... how do you account for users over the Internet coming fro=
m =
> multiple IP addresses? IP is not for authentication!
> =
> later...
> chad
> =
> > Hmm.. maintaing state with a CGI does not have to be that =
> > complicated...nor does it have to comprimise the investment people ma=
ke =
> > in paying for SSL capable commercially supported Web servers.
> > =
> > If one was to use the calling convention:
> > =
> > http://domain.com/cgiscript.exe/pathtofilename/file.htm
> > =
> > Then it would be very simple to write a small proxy CGI that kept sta=
te =
> > based on IP address, Basic HTTP authentication name, and last time th=
e =
> > user accessed a page. This would be sufficent and would not use all =
the =
> > resources that running 5000 concurrent webservers would. In the case=
you =
> > explained, there would also be a whole schlew of Denial of Service =
> > attacks I can think of right off the bat.
> > =
> > Ben Camp
> > =
> > =
> > On Sat, 21 Dec 1996, John W Pierce wrote:
> > =
> > > A few days ago, I sent out this algorithm in response to some quest=
ion:
> > > =
> > > http server accepts contact and starts the CGI script
> > > CGI script selects a random unused port
> > > send a redirection message to the client, sending it to the new po=
rt
> > > CGI script forks
> > > in the parent
> > > exit
> > > in the child
> > > start up some timeout procedure
> > > listen for the incoming connection
> > > process the request
> > > wait for more requests
> > > when we timeout or get some other "done" indication
> > > exit
> > > =
> > > Darren Cook noted:
> > > >
> > > > As this is on another port, the web server does not know about i=
t does it?
> > > > So the cgi script has to be a mini web server (eg. normally the =
web server
> > > > puts some information into environmental variables for your scri=
pt).
> > > > Or am I misunderstanding what you are suggesting?
> > > =
> > > You have understood it precisely. The intent here was a practical s=
olution
> > > to certain classes of "state maintenance" problems. The vast majori=
ty of the
> > > problems we see involve handling only POST and/or GET for forms ove=
r which we
> > > have full control. Under those conditions, implementation of just t=
hat portion
> > > of the HTTP protocol is trivial. I grant the potential philosophica=
l objections
> > > to such "abuse" of HTTP. However, this is solution is easier and mo=
re robust
> > > than any other we've seen and handles a lot of problems that would =
otherwise
> > > require Java to maintain a [true] virtual circuit to the backend. W=
e're not very
> > > fond of Java around here for several reasons, not the least of whic=
h is that
> > > using it usually increases implementation costs by a factor of two =
or three.
> > > =
> > > > However, if it was a secure connection, how do I keep it secure =
this way -
> > > > will my cgi script have to be not just a mini web server, but a =
mini
> > > > *secure* web server?!
> > > =
> > > In principle, that's correct. In practice, if this really can't be =
avoided then
> > > there are other solutions. For example, something like the above al=
gorithm can
> > > be done as a server "plugin". This is easier on some servers than o=
thers :-).
> > > =
> > > -- John W Pierce, R2 Systems, San Diego
> > > jwp@r2systems.com
> > > =
> > > =
> > > =
> > =
> =
> =
> =
> =
> =
> =
> =
