[3895] in WWW Security List Archive
RE: Maintaining state with CGI
daemon@ATHENA.MIT.EDU (Nathan Neulinger)
Mon Dec 23 19:44:27 1996
In-Reply-To: <01BBF0EC.436F0D00@silicon.geocel.com>
Date: Mon, 23 Dec 1996 17:07:07 -0600
To: Ben Camp <benc@geocel.com>, "'Chad Schieken'" <cschieke@advsys.com>
From: Nathan Neulinger <nneul@umr.edu>
Cc: John W Pierce <jwp@r2systems.com>,
"www-security@ns2.rutgers.edu" <www-security@ns2.rutgers.edu>
Errors-To: owner-www-security@ns2.rutgers.edu
This isn't correct. For the simple reason that you may have hundred of
users coming from the same IP address, with the same browser. For example,
AOL.
-- Nathan
At 4:13 PM -0600 12/23/96, Ben Camp wrote:
>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
>
>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
>> >
>> >
>> >
>>
------------------------------------------------------------
Nathan Neulinger Univ. of Missouri - Rolla
EMail: nneul@umr.edu Computing Services
WWW: http://www.umr.edu/~nneul SysAdmin: rollanet.org
