From nobody@hyperreal.com Tue May 6 00:08:50 1997 Received: (from nobody@localhost) by hyperreal.com (8.8.5/8.8.5) id AAA21955; Tue, 6 May 1997 00:08:50 -0700 (PDT) Message-Id: <199705060708.AAA21955@hyperreal.com> Date: Tue, 6 May 1997 00:08:50 -0700 (PDT) From: Michael Lipp Reply-To: mnl@dtro.e-technik.th-darmstadt.de To: apbugs@hyperreal.com Subject: Missing HTTP_AUTHORIZATION in CGI environment X-Send-Pr-Version: 3.2 >Number: 549 >Category: mod_cgi >Synopsis: Missing HTTP_AUTHORIZATION in CGI environment >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Class: change-request >Submitter-Id: apache >Arrival-Date: Tue May 6 00:10:01 1997 >Last-Modified: Wed Jan 21 14:33:27 PST 1998 >Originator: mnl@dtro.e-technik.th-darmstadt.de >Organization: >Release: 1.2beta10 >Environment: Linux mnlpc 2.0.30 #21 Sat Apr 19 16:30:12 MET DST 1997 i586 >Description: The "original" CERN Web-Server sets an environment variable HTTP_AUTHORIZATION when calling a CGI Script to the authorization string supplied by the browser (e.g. "Basic gasdfFjhgfjhg"). This allowed me to implement my own authorization scheme: (1) use a nph-script. (2) if HTTP_AUTHORIZATION is not set, respond "HTTP/1.0 401 Authorization failed\r", "WWW-Authenticate: Basic w3tdp\r". This causes the browser to prompt for username and password and to supply the authorization string with the next request. (3) Via HTTP_AUTHORIZATION this gets to my cgi-script and I can decode the base64 coded string and match the password against my own application specific password database. This is much easier to configure (and was supposed to be more portable) than using .htaccess files and htpasswd to modify some password file. I found, however, that apache does not supply this environment variable. I suppose it is not part of the CGI 1/1 definition. But as you can see, it is a very useful feature. >How-To-Repeat: Look at the environment of a CGI script. If you don't have access to a CERN-Server, I can make you an URL to test this available. >Fix: Pass the authentication-string in the CGI environment. I suppose I could create an apache patch myself. But if I want to distribute my CGI-based application, I can't ask people to patch their apache server as part of the installation process. >Audit-Trail: State-Changed-From-To: open-suspended State-Changed-By: marc State-Changed-When: Wed May 7 08:23:58 PDT 1997 State-Changed-Why: This is a conscious decision to not include it. It allows CGIs to do more evil things WRT stealing passwords from the browser's cache and on most Unixes you can view the environment of a process with the right arguments to ps. If HTTP_AUTHORIZATION was passed, that would be included. The only way it would be implemented would be as a config directive that let it be set for specific scripts in the config files, however 1.2 is in feature freeze so it will not happen before then. In the meantime, if your script really needs access to it you can either create a patch to remove the two lines special-casing the Authorization header in util_script.c or write a module that does what you want. I think there is also a mod_auth_external available somewhere that authenticates using an external program which can do whatever you want. State-Changed-From-To: suspended-closed State-Changed-By: dgaudet State-Changed-When: Wed Jan 21 14:33:27 PST 1998 State-Changed-Why: As of 1.3b4 whenver it is released you can add -DSECURITY_HOLE_PASS_AUTHORIZATION and mod_cgi won't apply this sanity check. Dean >Unformatted: