[4529] in WWW Security List Archive
Re: Question about User Identity (CGI scripting)
daemon@ATHENA.MIT.EDU (Brian W. Spolarich)
Thu Feb 20 11:37:52 1997
Date: Thu, 20 Feb 1997 09:21:24 -0500 (EST)
From: "Brian W. Spolarich" <briansp@ans.net>
To: Jim Harmon <jim@telecnnct.com>
cc: Jeremey Barrett <jeremey@veriweb.com>, daver@idiom.com,
www-security@ns2.rutgers.edu
In-Reply-To: <330B7B36.6E9DAAD9@telecnnct.com>
Errors-To: owner-www-security@ns2.rutgers.edu
On Wed, 19 Feb 1997, Jim Harmon wrote:
| The users are on the same system as the server. In my case, my personal
| account is on Server B and the CGI is running on server A. The other
| users are actually logged and funning their browsers on server A.
|
| For all intents and purposes the clients and server should be the same
| system... for our setup on this problem.
Right, but they're connecting to the HTTP server over the network (even
if they connect to "localhost" they're still going through the loopback
network interface), which does not run as them, but as "nobody" or some
other unprivileged user. So any authentication credentials (such as what
the kernel might present as the UID of the running process) are
demultiplexed into whatever the web server is running as.
| > Finding out the user's login on _his_ system requires an ident query,
| > sent by the web server to the identd daemon on the user's machine.
| > This is sent to a CGI in $REMOTE_IDENT, and should _not_ be used
| > as the basis for authentication, as 1) it is trivially faked, and 2)
| > most machines (especially windoze), do not run identd daemons.
|
| Ok, since we're on an Intranet, and this server is not visible to the
| Internet, and because most of the users are on the server itself, I'm
| having trouble seeing where "$REMOTE_anything" will work, even with
| identd running. Am I just being flakey on this issue?
Maybe we're all being flakey...its hard to communicate via email. :-]
You should be able to (somewhat) trust identd if:
- the client system (i.e. the system that the users are running their
browsers on) accepts identd connections, and is running identd (either via
inetd or standalone)
- the identd service is not available to outside users. I would do this
by a combination of 1) filtering at the firewall or gateway router 2)
wrapping identd connections so they can only come from a limited range of
hosts. You can do this either with tcpd or ip-filt. Haven't done much
with ip-filt, but it looks pretty cool.
- your HTTP server is configured to attempt to make the identd
connection back to the client.
This isn't particularly portable authentication, though, as it won't
succeed if someone dials in from home, establishes a PPP session, and then
attempts to connect to your web server, as their remote workstation would
have to supply the identd info, which I definitely would not trust. This
is the equivalent of this authentication handshake:
Alice: "Who are you?"
Fred: "I'm Bob."
Alice: "Bob? Really?"
Fred: "Yes."
Alice: "Well, okay. Here you go, Bob."
| > As far as "Real Name", you might want to investiate using X.509
| > certificates as your authentication mechanism, which will allow
| > you to put some reasonable information in the certificate.
| > XCert (www.xcert.com) is doing this stuff, as are others.
|
| Is it really necessary inside a closed system to use certs?
|
| I know this is rather petty of an issue, but I have users who are very
| set in how they work. The additional login to access our web server
| would not sit well with most of them, but I can see benefits with that
| in place. Primarily that we're starting to think about letting some
| power users and administrative staff do take-home work.
|
| Authentication is absolutley necessary in that regard, so moving that
| direction in general will probably ease the case for allowing the
| piercing of our access envelope.
|
| Thanks everyone so far, I haven't replied to all responces, and I will
| post a summary by monday (2/24).
What I would seriously recommend is that you inform your users that
they're going to have to authenticate to the web server in order to access
certain resources, and use HTTP Basic authentication. One nice thing you
can do is if you're using typicial Unix authentication (passwd files or
NIS/NIS+) is that you can take the contents of the Unix password file (or
a subset) and use that as the authentication database for your web server.
This means that the users will have to type in a username/password to
access the web server (or a subset of resources), but it will be the same
username/password that they use to log on all the time.
I wrote something like this to support an application used by our Web
Hosting customers. See http://www.lymehouse.com/devoto/passwd.html (the
context of this reference is the Netscape v.1 and v.2 servers) for an
example in Perl. Unfortunately the code lost its indenting and comments,
but its very simple.
Its not the most elegant solution in the world, but it works. There's
the whole issue of passwords in the clear, but most people still telnet to
Unix boxes these days, so what are you going to do?
-brian
--
Brian W. Spolarich - ANS Systems Development - briansp@ans.net - 313-677-7311
At the sight of Nothing the Soul rejoices. -- Thomas Moore
