[3896] in WWW Security List Archive
RE: Maintaining state with CGI
daemon@ATHENA.MIT.EDU (Ben Camp)
Mon Dec 23 19:47:20 1996
From: Ben Camp <benc@geocel.com>
To: Ben Camp <benc@geocel.com>, "'Chad Schieken'" <cschieke@advsys.com>,
"'Nathan Neulinger'" <nneul@umr.edu>
Cc: John W Pierce <jwp@r2systems.com>,
"www-security@ns2.rutgers.edu"
<www-security@ns2.rutgers.edu>
Date: Mon, 23 Dec 1996 17:13:09 -0600
Errors-To: owner-www-security@ns2.rutgers.edu
I agree, in the case of users coming from a proxy server then you must =
somewhat rely on the REMOTE_USER variable and that only coming from one =
IP address.
Ben Camp
----------
From: Nathan Neulinger
Sent: Monday, December 23, 1996 5:07 PM
To: Ben Camp; 'Chad Schieken'
Cc: John W Pierce; www-security@ns2.rutgers.edu
Subject: RE: Maintaining state with CGI
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
