[3879] in WWW Security List Archive
Maintaining state with CGI
daemon@ATHENA.MIT.EDU (John W Pierce)
Sun Dec 22 03:46:00 1996
From: John W Pierce <jwp@r2systems.com>
To: "www-security@ns2.rutgers.edu" <www-security@ns2.rutgers.edu>
Date: Sat, 21 Dec 1996 22:58:15 -0800
X-MDaemon-Deliver-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
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
