[3885] in WWW Security List Archive
Re: Maintaining state with CGI
daemon@ATHENA.MIT.EDU (Benjamin Camp)
Sun Dec 22 17:21:22 1996
Date: Sun, 22 Dec 1996 14:31:17 -0600 (CST)
From: Benjamin Camp <benc@geocel.com>
To: John W Pierce <jwp@r2systems.com>
cc: "www-security@ns2.rutgers.edu" <www-security@ns2.rutgers.edu>
In-Reply-To: <01BBEF92.7880EF00@jwp5.extern.ucsd.edu>
Errors-To: owner-www-security@ns2.rutgers.edu
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
>
>
>
