[3893] in WWW Security List Archive
RE: Maintaining state with CGI
daemon@ATHENA.MIT.EDU (Ben Camp)
Mon Dec 23 18:41:16 1996
From: Ben Camp <benc@geocel.com>
To: Benjamin Camp <benc@geocel.com>, "'Chad Schieken'" <cschieke@advsys.com>
Cc: John W Pierce <jwp@r2systems.com>,
"www-security@ns2.rutgers.edu"
<www-security@ns2.rutgers.edu>
Date: Mon, 23 Dec 1996 16:13:40 -0600
Errors-To: owner-www-security@ns2.rutgers.edu
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 =
course 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 really 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=20
Ben,
Your close... how do you account for users over the Internet coming from =
multiple IP addresses? IP is not for authentication!
later...
chad
> Hmm.. maintaing state with a CGI does not have to be that=20
> complicated...nor does it have to comprimise the investment people =
make=20
> in paying for SSL capable commercially supported Web servers.
>=20
> If one was to use the calling convention:
>=20
> http://domain.com/cgiscript.exe/pathtofilename/file.htm
>=20
> Then it would be very simple to write a small proxy CGI that kept =
state=20
> based on IP address, Basic HTTP authentication name, and last time the =
> user accessed a page. This would be sufficent and would not use all =
the=20
> resources that running 5000 concurrent webservers would. In the case =
you=20
> explained, there would also be a whole schlew of Denial of Service=20
> attacks I can think of right off the bat.
>=20
> Ben Camp
>=20
>=20
> On Sat, 21 Dec 1996, John W Pierce wrote:
>=20
> > A few days ago, I sent out this algorithm in response to some =
question:
> >=20
> > 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 =
port
> > 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
> >=20
> > Darren Cook noted:
> > >
> > > As this is on another port, the web server does not know about it =
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 =
script).
> > > Or am I misunderstanding what you are suggesting?
> >=20
> > You have understood it precisely. The intent here was a practical =
solution
> > to certain classes of "state maintenance" problems. The vast =
majority of the
> > problems we see involve handling only POST and/or GET for forms over =
which we
> > have full control. Under those conditions, implementation of just =
that portion
> > of the HTTP protocol is trivial. I grant the potential philosophical =
objections
> > to such "abuse" of HTTP. However, this is solution is easier and =
more 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. =
We're not very
> > fond of Java around here for several reasons, not the least of which =
is that
> > using it usually increases implementation costs by a factor of two =
or three.
> >=20
> > > 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?!
> >=20
> > 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 =
algorithm can
> > be done as a server "plugin". This is easier on some servers than =
others :-).
> >=20
> > -- John W Pierce, R2 Systems, San Diego
> > jwp@r2systems.com
> >=20
> >=20
> >=20
>=20
