(no subject)

no email ()
Wed, 9 Feb 1994 20:32:50 --100

The other day I got a curious message from someone asking why CGI didn't
make the value of the From: HTTP header available to scripts. The immediate
answer is "Because Rob didn't know about it at the time". However, the
person went on to describe what they wanted to use it for: an insecure
method of access control.

I was wondering just where the heck someone would get such an idea, until I
looked at the HTTP spec:

-- Excerpt: http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTRQ_Headers.html


In Internet mail format, this gives the name of the requesting user. This
field may be used for logging purposes and an insecure form of access
protection. The interpretation of this field is that the request is being
performed on behalf of the person given, who accepts responsability for the
method performed.

-- End of excerpt

BTW the word responsability is a typo, probably should be fixed.

Is this really something we want to encourage? "The request is being
performed on behalf of the person given, who accepts responsibility for the
method performed."

Calling this unsecure is an understatement. I sure don't want to take
responsibility for a method which I didn't necessarily perform. The only
case in which such a setup should be considered is one in which your
protected documents are not accessible by *anyone* outside a group of people
whom you trust not to use telnet and abuse this service. Physical network
barriers would be enough, except that you then have to place a great deal of
trust in every person who has access to the specified subnet or list hosts.

I think we need to change this section to read that From: is to be used for
logging purposes only, and strike the mention of insecure form of access
protection and the section on the person given accepting responsibility for
the method performed. The only access protection this would provide is
applicable in such a limited context that the information in From: is not
useful for more than logging information anyway.