[3892] in WWW Security List Archive
Re: Maintaining state with CGI
daemon@ATHENA.MIT.EDU (Chad Schieken)
Mon Dec 23 18:33:07 1996
To: Benjamin Camp <benc@geocel.com>
cc: 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 "Sun, 22 Dec 1996 14:31:17 CST."
<Pine.BSF.3.91.961222142653.15516C-100000@lithium.geocel.com>
Date: Mon, 23 Dec 1996 16:40:07 -0500
From: Chad Schieken <cschieke@advsys.com>
Errors-To: owner-www-security@ns2.rutgers.edu
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
> complicated...nor does it have to comprimise the investment people make
> 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 state
> 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
> 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 question:
> >
> > 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
> >
> > 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?
> >
> > 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.
> >
> > > 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 algorithm can
> > be done as a server "plugin". This is easier on some servers than others :-).
> >
> > -- John W Pierce, R2 Systems, San Diego
> > jwp@r2systems.com
> >
> >
> >
>
